Hacker Newsnew | past | comments | ask | show | jobs | submit | jngiam1's commentslogin

I totally agree, we’ve been working with enterprises and MCP is the defacto way they are using agents with data.

We build a gateway (MintMCP) and I’d love to connect and exchange notes.

We’re excited about XAA, it will simplify many flows


I don't get why everything is not marked as sensitive in env vars by default instead.


MCP tools. We're doing some MCP bundling and giving it here, pretty cool stuff.


wasn't MCP a critical link in the recent litellm attack?


And if it was?

It's a bit like asking if "an API" was a critical link in some cybersec incident. Yes, it probably was, and?


i'd say it's more like intentionally choosing to use naive string interpolation for SQL queries than a trusted library's parameter substitution. Both work.


There is no "parameter substitution" equivalent possible. Prompt injection isn't like SQL injection, it has no technical solution (that isn't AGI-complete).

Prompt injection is "social engineering" but applied to LLMs. It's not a bug, it's fundamentally just a facet of its (LLM/human) general nature. Mitigations can be placed, at the cost of generality/utility of the system.


> It's not a bug, it's fundamentally just a facet of its (LLM/human) general nature

Fair enough but then that means that MCP is not "a bit like asking if "an API" was a critical link in some cybersec incident"

Because I can secure an API but I can't secure the the "(LLM/human) general nature."


MCP itself is just an API. Unless the MCP server had a hidden LLM for some reason, it's still piece of regular, deterministic software.

The security risk here is the LLM, not the MCP, and you cannot secure the LLM in such system any more you can secure user - unless you put that LLM there and own it, at which point it becomes a question of whether it should've been there in the first place (and the answer might very well be "yes").


This is powerful. Combined with MCPs, you can pretty much automate a ton of work.


Can you give some examples?


That feature was silent launched about week ago for me.

I use it to:

- perform review of latest changes of code to update my documentation (security policies, user documentation etc.)

- perform review to latest changes of code, triage them, deduplicate and improve code - I review them, close them with comments for over-engoneering / add review for auto-fix

- perform review of open GitHub issue with label, select the one with highest impact, comment with rationale, implement it and make pull request - I wake up and I have a few pull request to fix issues that I can approve /finish in existing Claude Code thread

I want also use it to: - review recent Sentry issues, make GitHub issues for the one with highest priority, make pull request with proposed fix - I can just wake up and see that some crash is ready to be resolved

Limit of 3 scheduled jobs is pretty impactful, but playing with it give me a nice idea on how I can reduce my manual work.


Maybe I’m missing the point but we have some of these implemented without the tool - the only one that needs an API key is the log scraping. It’s been surprisingly cheap and if we want to swap models we can.


Of course, this scheduled can be implemented on top of existing tools. However, it's incredibly convenient to have a UI where:

- you can easily edit the prompt

- you can see the prompt execution history

- you don't need any infrastructure to orchestrate it

- it works even when your computer is off

Once you start using it, it turns out to be very convenient.


We built a very similar thing! Also with git, very nice- if you’re looking for an enterprise ready version of this, hit me up

Love to discuss and see how we can make this more standard



https://news.ycombinator.com/item?id=47208398

https://news.ycombinator.com/item?id=47157398

IMHO, CLI tools are better more often than not against MCP.

EDIT: and here is similar opinion from author himself: https://news.ycombinator.com/item?id=47252459


Exactly. and even if so, how are you going to safe guard tool access?

Imagine your favorite email provider has a CLI for reading and sending email - you're cool with the agent reading, but not sending. What are you going to do? Make 2 API keys? Make N API keys for each possible tool configuration you care about?

MCPs make this problem simple and easy to solve. CLIs don't.

I don't think OpenClaw will last that long without security solved well - and MCPs seem to be obvious solution, but actively rejected by that community.


Supposedly, you make a Skill for it, but even that is out of scope for chat agents. I didn't scroll far, but I wouldn't be surprised more people in this thread have made the mistake of giving that answer.


I think if you want background agents with sandboxes and well scoped permissions, you want MCP to be your data protocol and security layer.

If you’re vibing and doing the open claw thing without any security concerns; then you’re absolutely right.


The Skills I have for Claude are all based on personal preferences and reflects the setup I have going. It's a way to narrow the probability space to the specific set which works really well for me.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: