←back to thread

MCP is eating the world

(www.stainless.com)
335 points emschwartz | 1 comments | 21 Jun 25 16:30 UTC | HN request time: 0.001s | source
Show context
faxmeyourcode ◴[24 Jun 25 16:58 UTC] No.44368295[source]▶
Based on the comments here, a lot of folks are assuming the primary users of mcp are the end users connecting their claude/vscode/etc to whatever saas platform they're working on. While this _is_ a huge benefit and super cool to use, imo the main benefit is for things like giving complex tool access to centralized agents. Where the mcp servers allow you to build agents that have the tools to do a sort of "custom deep research."

We have deployed this internally at work where business users are giving it a list of 20 jira tickets and asking it to summarize or classify them based on some fuzzy contextual reasoning found in the description/comments. It will happly run 50+ tool calls poking around in Jira/confluence and respond in a few seconds what would have taken them hours to do manually. The fact that it uses mcp under the hood is completely irrelevant but it makes our job as builders much much easier.

replies(7): >>44368648 #>>44368903 #>>44368929 #>>44368954 #>>44369304 #>>44374580 #>>44375982 #
dkdcio ◴[24 Jun 25 17:57 UTC] No.44368903[source]▶
Where I struggle conceptually is this works fine without MCP.

Write a CLI tool that does the same thing (including external service access) and tell any agentic CLI tool (or Cursor or IDE tool) to use the tool. Much simpler, established security models, etc.

replies(9): >>44369240 #>>44369266 #>>44369268 #>>44369270 #>>44369365 #>>44369912 #>>44371239 #>>44371639 #>>44372125 #
__MatrixMan__ ◴[24 Jun 25 22:17 UTC] No.44371639[source]▶
I'll take a CLI over http ten times out of ten. However, I'm skeptical that that's the ideal long term interface because it gives the model too much freedom.

I want to be the one deciding which CWD to use, which user to run as, whether to see the whole filesystem or to restrict to a chroot, etc.

So far it hasn't been malicious but I've had a number of cases while using cursor where the model has gotten confused and is now editing repos outside the open workspace.

Maybe the answer is still a CLI, but I want a standardized interface for equipping that CLI with handcuffs.

replies(1): >>44372466 #
apitman ◴[25 Jun 25 00:18 UTC] No.44372466[source]▶
Are there any tools that automate using containers for this?
replies(1): >>44377576 #
1. __MatrixMan__ ◴[25 Jun 25 14:13 UTC] No.44377576[source]▶
You could just start the MCP server in container I guess, although I suppose that's doing it the manual way.

That might prevent the model from wandering from the beaten paths, but container escapes are a thing, so if it's not lost but instead malicious then that might not do it. Luckily I don't think we're quite there yet.

So I think that's a "no".

QubesOS might work well for this. It's all about making it easy to work with a small pile of VMs under the assumption that at least one is probably compromised and keeping that one compartmentalized. Although I don't know how far that'll get you if you're letting the untrusted thing call the shots.

At the end of the day you're always going to be able to build better handcuffs by starting with nothing and gradually adding API calls that it needs. Starting with CLI access and then adding restrictions is never going to be as secure, even though it's way more convenient.

That said, I think you could strike a pretty reasonable balance by just not giving it access to anything but one or two explicitly chosen directories.