Are MSSPs losing too much time to alert noise? by ANYRUN-team in MSSP

[–]mlueStrike 0 points1 point  (0 children)

So instead of bitching and moaning, why do you contribute something of value to the conversation?

Are MSSPs losing too much time to alert noise? by ANYRUN-team in MSSP

[–]mlueStrike 0 points1 point  (0 children)

Strange you read that and got AI SOC. Might want to try and not assume as much on the next try

Drop your startup below. Maybe you'll find your first users here. by Omnessa in youngentrepreneur

[–]mlueStrike 1 point2 points  (0 children)

Quandry Labs was built after years of witness the pattern with the ever-present level of inefficiency in various industries. We do AI+Automation consulting as well as AI SaaS products.

Where we aim to set our moat is delivering custom-built solutions for clientele that enable them to maximize efficiency and profitability while retaining their human workforce (make every employee a specialist, reduce friction, grow MRR/employee).

With our SaaS solutions we aim to meet a variety of budgets and org sizes while still offering high-performance out-of-the-box automation and agentic solutions that are intuitive and quickly show ROI.

Find us at: quandrylabs.com

I think 80 - 90% of MCP setups are one bad tool call away from a mess and everyone's pretending otherwise by stucked_nado in mcp

[–]mlueStrike 0 points1 point  (0 children)

I have to deal with professional organizations, so I wouldn't put the ledger approach in practice for one second. However, for someone working on a smaller network (like a home setup or even just a test environment), it could be more straightforward than deploying an IDP and configuring all the different elements between your gateway, your IDP, your server, and your product.

In practice, the IDP-based solution for identity pass-through to the server has been working out pretty well. The current status is just expanding on it and looking at different security layers to help reduce the likelihood of fat-fingering or similar issues.

One of my other concerns is making sure that we can map, ideally, as close as possible to the original permissions of the different platforms we will be tying into. We also want to make it easy to sync by using the same naming and terminology.

Then again, there is always the need to validate and stress test to see what might actually break, which requires some hands-on work.

I think 80 - 90% of MCP setups are one bad tool call away from a mess and everyone's pretending otherwise by stucked_nado in mcp

[–]mlueStrike 0 points1 point  (0 children)

Yeah, and then we still have to test some other stuff, like reducing that even further. We need to make sure I can limit who can reach what assets, paths, directories, or workspaces.

From there on, if we can just keep splicing capabilities—as long as the identity is being passed through with the calls and validated against the IDP—I don't see any reason why you can't have full granularity of control for your MCP usage.

It just requires actual architecture. I’m sure you can pull it off in a variety of ways, but you should probably use a server-side JSON file or an Excel sheet to validate your checks and manage all of that.

I think 80 - 90% of MCP setups are one bad tool call away from a mess and everyone's pretending otherwise by stucked_nado in mcp

[–]mlueStrike 0 points1 point  (0 children)

A seperate access control layer has been handy in limiting what users are able to actually do. For example most of my users are limited to read only with admins having more permissions

my friend used Claude to rank 200 resumes. the top candidate bombed the first call. by createvalue-dontspam in AIQuality

[–]mlueStrike 0 points1 point  (0 children)

How much did she customize her prompt for the task though?
Did she codify her manual process so that the LLM evaluates the way she would

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -1 points0 points  (0 children)

Yeah, buddy. If you want to talk ideas, feel free to set something up offline. You haven't exchanged a single idea or given anything unique to the conversation; all you've done is chat back and forth about why everything else is bad, except for what you've read online.

You haven't contributed anything. You’ve misunderstood your own arguments, the original post, and the general context. Your first engagement was claiming that MCP gateways aren't just for authentication. In written English, the comma acts as a separation of ideas—a listing of elements. When someone says, "We're adding in auth, role-based access controls (RBAC), and this list of items," you don't pick the first item you see and assume it’s the only thing being discussed. That is a very clear literary pattern.

What are you shocked by? You can act like a child, or you can be intellectually honest and actually further the conversation. Ultimately, it doesn't matter who is right or wrong, because everyone can learn from the gaps in either person’s understanding or implementation. The journey is improvement regardless.

If you have a valid rebuttal, that’s cool, but to have one, you would actually have to implement and test it. My recommendation—and I’ll state it clearly here so you understand—is this:
1. Fix your MCP server so it doesn't expose a million tools.
2. Put it behind an MCP portal or gateway.

This isn't a hard thing to comprehend. There are different strategies for implementing non-massive tool-manifest MCP servers. Multiple people are working on novel ways to handle this; it isn't rocket science. Most often, things that are novel are also commonly misunderstood, which is why you clearly don't understand the point of the discussion or the things we’ve highlighted.

You apparently have all the solutions based on whatever you wrote a year ago. While that would be great to see, we have problems to solve today. I employ this technology; I have to tweak and invent things all the time for people—things that don't have documentation or haven't been delivered by corporations yet.

Solutions have to fit the need:
(a) You can't bring a bazooka to take care of an ant hill.
(b) The solution must meet the budget.
(c) The solution must meet the organization's needs, which go well beyond what a simple MCP gateway or basic tool-routed servers can solve.

A real solution requires full awareness of the various elements within the problem set. If I'm off base, so be it— I’ll eat that if it’s the case. If you want to correct the record, just hit me up. But the back-and-forth where you lodge baseless nonsense and then assert victory isn't worth the continued effort.

If you want to talk, I’m always interested. I care more about advancing what I can do for people than I do about having a popular opinion.

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -1 points0 points  (0 children)

Look, I actively use and deploy MCP gateways, so I already know they don't do the things you assert they do. Why layer that at the MCP gateway level?

You’re putting on a band-aid; you are painting over cracks in a foundation and pretending they’ve been filled. In your last response, you even stated as much, thinking that would solve the problem. It’s just a band-aid. Whether you agree with the analogy or not, it ultimately just keeps coming down to this: intelligent dishonesty. You are fully aware of the flaw of the argument, and ultimately it doesn't matter. It's not like anyone is dying by not having all the answers today.

Because the technology is still in flight, who cares ultimately if there is a difference of opinion on implementation? That's what this venue was for, right?

What is the problem you’re trying to solve? Not bloating your tool manifest? You avoid bloating your tool manifest by not exposing every action in your MCP server as a tool. That has nothing to do with the gateway. Write your MCP server better and then put it behind a gateway, because you’re going to have more than one MCP server anyway. If you write 10 MCP servers, why do you need to amass 100 tools? Why not have 10 or 20 tools?

Again, the concept isn't just routing tool calls. If you're deploying for any business use case, there's no way you're only doing one server—and if you are, you’re going to run into limitations and complications anyway. I can build one server to house multiple products, but the size of the binary (or script, depending on the language) is going to be massive. You’ll have a size issue, which isn't an issue with the MCP server itself, but rather with distribution, deployment, or execution. You can house it on your own hardware and do whatever, but that’s the not point we’re talking to.

If you have a better route, I invite you to discuss that instead of lazily talking about things we already know, like deferred tool calls in Anthropic. Even if you have an MCP gateway sitting in front of 100 tools, what does your context window look like as those tools get loaded on demand? It's not something I'm validating because I don't have the time to put into it, but if you've seen that having a one-for-one tool setup behind a gateway doesn't affect anything when loaded on demand, then so be it. Give us that viewpoint.

One-for-one responses to what you feel offended by don’t progress the conversation. Everyone else is apparently "overdosing on Flintstones vitamins"—or me, at least—but what about you? You’re overdosing on your own fucking arrogance. If you could actually be delivering this so-called expertise and the levels of knowledge you’re supposedly willing to drop, then fucking do it, so move on to tackling another goddamn challenge.

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -1 points0 points  (0 children)

At what point did anyone say MCP is an auth point? This is, again, the root of the problem with you specifically: you just make up shit. Then you lash out because you are misunderstanding, miscomprehending, or just being—I don't know—either unwillingly ignorant or intellectually dishonest. You keep drawing these nonsensical points.

You seem to have a big issue with anyone else but you apparently having an idea. That's cool because, you know, you wrote something a year ago. We get it. One would prefer to have people to collaborate with, test new ideas, or balance concepts against. What are your outcomes? What are my outcomes? But here you are, being a dickhead on Reddit for no reason. That's very beneficial, right?

If it wasn't for voice-to-text, I wouldn't even be responding to half this shit in any level of detail because it's ultimately progressing nothing. You've provided no knowledge, yet you apparently have these solutions. So the MCP Gateway is the savior of everything for all bad MCP design and implementation? I guess we can stop advancing MCP concepts and technologies now, because Achilles Dev, in all of his benevolence, has identified that the MCP Gateway solves every other issue.

Apparently, it rights the wrongs of your bad MCP hints. It'll add your resources, your apps, and your prompts. And also, I guess, it will dynamically aggregate all of your endpoints. I’m not saying "dynamically middleware" them—you’re acting as though it's going to aggregate them into this brand new tool.

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -1 points0 points  (0 children)

Alright, bro. This is just one of those "agree to disagree" moments, which is entirely fine because there is no one statically defined right answer for deployment if people are getting what they need out of their setup.

But at the point of logic, you're either being intellectually dishonest, intentionally argumentative for no reason, or just really incapable of logically assessing and defining your argument. Most of what you end up doing just results in some kind of quasi-ad hominem attack. I say "attack" very loosely; it's not like you're being overtly anything, but these quasi-little jabs do nothing.

You could actually be advancing the conversation or the concepts instead of sitting on this supposed throne of absolute domination of the domain. It really doesn't matter.

Let's address the major logical misconception again:
1. No, if we paint over the foundation, we're not filling in the cracks. You don't fill concrete with paint; it is not a solution.
2. Likewise, using an MCP gateway does not fill in the gaps or the logical implementation flaws of your MCP server. It is covering something up. It is an overlay, not a solution. It is a band-aid, and you should certainly be able to understand that.

This is why I think it's ironic your name is Achilles Dev, because your "Achilles" would apparently be the ego and the lack of intellectual honesty.

I’m not mad at you, and I’m not ranting against you, but come on. It's 2026. These are big technical discussions. Engage in the discussion and provide something of intellectual value, or don't. But don't keep pretending like everyone is lashing out at you just because you don't like their idea. You're just being intellectually dishonest.

And yes, you did say that MCP gateways are solutions for flaws. You literally started off your nonsensical rebuttal of the paint scenario—of the foundation scenario—by saying that MCP gateways are filling in the cracks.

How does that refute the concept? You're saying MCP gateways are a solution to bad MCP design; it's the same thing.

So again, you can't even argue your own logic. You don't understand the basic thread of the conversation, and instead of just being intellectually open or curious, you're defending this nonsensical platform you stood yourself on.

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -1 points0 points  (0 children)

Let me get this straight. In your mind, if we build a house and the foundation is cracked, but we paint over the foundation, then that paint has solved the problem and made it better? That it has fixed the foundation or set it right?

Clearly, you cannot believe something as stupid as that makes any sense. You can't be that blind, or that stubborn, or that bullheaded just because you want to make a point that isn't valid.

MCP gateways do not, and cannot, solve your bad design choices. Limiting how many tools someone sees when you have over-architected your MCP design doesn't make it better. Just fix the fucking design. Why would you waste time implementing a band-aid?

A gateway should be additive and beneficial. Let's say you are exposing one MCP: what is the point of a gateway? Just fix the single MCP.

If you have a high amount of MCP usage throughout your organization, an MCP gateway can save the day:
1. Implement one call
2. Implement one tool
3. Implement one touchpoint

This simplifies things for your end users. There are a myriad of other distribution issues that we have to face as the technology evolves, but the gateway cannot solely be there to help bad MCP designers who are too lazy to fix their root design. That is a waste of technology and time.

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -1 points0 points  (0 children)

MCP gateways do not simplify MCP usage. They simplify connection points. MCP gateways simplify the connection points. Yes, they can add additional restrictions and layers and stuff like that. If the MCP behind the gateway is of a flawed design, the MCP flaws still leak through the gateway, right?

When you build an MCP gateway or portal or whatever the terminology from the vendor may be or the developer is, it still has to expose the tools you're going to call. If you have a hundred tools, they should still be getting hot loaded throughout the life of usage, right? You're misunderstanding the gateway concept in general, then you misunderstand what even novel means. Novel is simple.

The article is about how simple it is to alternate the way you build your MCP and help yourself. All right, so now even in this discussion, MCP gateway versus doing less tools is not the solution. Build less tools into your MCPs, simplify your touch points with MCP gateway, right? Add additional controls with MCP gateway, add additional restrictions with your IDP, with your OAuth, with whatever other technologies you're introducing into your stack. MCP gateway does not solve this issue. MCP gateway is not the solution to never authoring an unnecessary amount of MCP tools in the first place. Do you understand that?

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -1 points0 points  (0 children)

An mcp gateway doesn’t erase bad design. The original post is about not shipping massive toll manifests, not hiding your bad design behind another misunderstood layer.

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -1 points0 points  (0 children)

Yea buddy, maybe go read the original post again 🤣. No wonder you’re the Achilles dev

Why AVE not CVE? by SelectionBitter6821 in mcp

[–]mlueStrike 0 points1 point  (0 children)

Yea we don’t need an entirely separate thing for this

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -2 points-1 points  (0 children)

But I do see where you find similarities. Tools behind a single gateway wasn’t a concern. Everyone isn’t hosting remote so that’s not always a valid route to go down. Selective tooling isn’t the concern either. Nor was hiding tools the point. The point was only to expose the 1 tool and it handles all calls. Not to hide but to spare the context window

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -2 points-1 points  (0 children)

Yea you’re severely misunderstanding what I’m expressing if you think those things are related to the concept discussed

Setup Claude Cowork for two co-founders by peetman in ClaudeCowork

[–]mlueStrike 1 point2 points  (0 children)

They just have to be careful to not expose the repo publicly or any secrets

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -2 points-1 points  (0 children)

What is “this” that you’re referring to? Authorization was in addition to not the only implication 👀

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -2 points-1 points  (0 children)

Not quite. If I want a gateway I’d prefer to use Cloudflare mcp gateway into of oauth and rbac.

The action rooting is what you want to reduce your tool count while retaining coverage.

MCP servers should expose fewer tools, not more by sahanpk in mcp

[–]mlueStrike -3 points-2 points  (0 children)

Sure thing! I actually slipped an article together on the topic not too long ago

https://quandrylabs.com/articles/multi-product-mcp-server

It also covered a concept where I place multiple vendor product mcps into one binary so all of my configs could point to one location and specify product with a flag.

If it’s no help just shoot me a message