The “S” in MCP Stands for Security

Another bad standard designed by those who don't consider security as important. Which is why we have this excellent article. Essentially it's somehow fashionable to have remote-code-execution as a service by dumb agents executing anything they see when they use the MCP.

Once one of those exploits are executed, your keys, secrets and personal configs are as good as donated to someone else's server and also sent back to the LLM provider.

This shows that we can also see how dangerous widely used commands like curl | bash can be, despite the warnings and security risks.

The specification might as well have been vibe-coded.

ragarding to the unverified mcp concerns, this is the same reason i chose OCI.

i chose OCI format for plugin packaging in my hyper-mcp project in order to leverage all the security measurements we have with OCI like image signing, image verification etc...

i chose wasm to sandbox each plugin so that they have no network or filesystem access by default

https://github.com/tuananh/hyper-mcp

About spit out my coffee, hilarious title.

Also the O is for Observability. I've been knee-deep in exploring and writing MCP servers this week. Most of the implementations, including my toy ones, do not have any auditing or metrics. Claude stores log output of the MCP servers, but that is geared more for debugging than for DevOps/SecOps.

Culturally, the issues OP describes are a big problem for soft-tech people (muggles). On the subreddits for this stuff, people are having a great time running MCP CLI programs on their machines. Much of OP security comments are obvious to developers,(although some subtleties are discussed in this thread), but these users don't have the perspective of how dangerous it is.

People are learning about Docker and thankfully Claude include its usage in their examples. But really most people are just downloading blobs and running them. People are vibe-coding MCP servers and running those blindly!

As MCP takes off, frameworks and tooling will grow to support Security, Observability, etc. It's like building web stuff in the mid-90s.

Unrelated to OP, but I gotta say, in building these it was so exciting to type something into Claude Desktop and then trigger a breakpoint in VSCode!

I enjoyed reading your notes, thanks for sharing.

On "Zero reuse of existing API surfaces", I read this insightful Reddit comment on what an LLM-Tool API needs and why simply OpenAPI is not enough [1].

On "Too Many Options"... at the beginning of this week, I wrote an MCP server and carefully curated/coded a MCP Tool surface for it. By my fourth MCP server at the end of the week, I took a different approach and just gave a single "SQL query" endpoint but with tons of documentation about the table (so it didn't even need to introspect). So less coding, more prose. For the use case, it worked insanely well.

I also realized then that my MCP server was little more than a baked-in-data-plus-docs version of the generalized MotherDuck DuckDB MCP server [2]. I expect that the power will be in the context and custom prompts I can provide in my MCP server. Or the generalized MCP servers need to provide configs to give more context about the DBs you are accessing.

[1] https://www.reddit.com/r/mcp/comments/1jr8if3/comment/mlfqkl... [2] https://github.com/motherduckdb/mcp-server-motherduck