[Pakvothe]

This is interesting for MCP server deployment. Right now most MCP servers run as local stdio processes. Containerizing them would solve the security and isolation concerns that come up every time someone installs a thirdparty MCP server.

Would love to see this support stdio-to-HTTP bridging so local MCP servers can be exposed as remote ones without rewriting them.

[jsunderland323]

There a couple of ways you can go about MCP within coasts (also depends on what the MCP does). You can either install the MCP service host-side (something like playwright), in which case everything should just work out of the box for you.

Alternatively, you can setup the Coast to install MCP services in the containers. There are some cases around specific logging or db MCP's where this might make sense.

>Would love to see this support stdio-to-HTTP bridging so local MCP servers can be exposed as remote ones without rewriting them.

Are you saying if you exposed the MCP service in the Coast and hosted it remotely you could expose back the MCP service remotely? That's actually a sort of interesting idea. Right now, the agents basically need to exec the mcp calls if they are running host-side and need to call an inner mcp. I hadn't considered the case of proxying the stdout to http. I'll think about how best to implement that!

[cyanydeez]

Isn't the primary security concern with thirdparty MCP servers the actual injected context and not whatever sandbox the MCP server is in? It doesn't really matter if the MCP can't do something to it's host; it's that it can manipulate the context to whatever ends it deems fit, which then is intractable in whatever LLM is calling it.

I'm really struggling to understand what peoples security concepts are with LLMs.

[TZubiri]

There's this naïve approach to security that obsesses with building walls, because walls are secure and nothing gets through.

Apparently a lot of people get nerd sniped into building impenetrable 10meter thick steel walls instead of thinking about doors and the windows.

[sReinwald]

Third-party MCP servers create at least two different security problems. One is prompt/context injection through the tool output. The other is the much more conventional risk of executing untrusted code with transient dependencies on your machine (which is how the recent litellm compromise was discovered).

Containerization only helps with the second one, not the first, but that still matters. If you’re going to run random third-party MCP servers, isolating them from your host and any sensitive local data is still an obvious improvement over no isolation.