Isn't the MCP endpoint that allows AI agents to run custom SQL queries, essentially letting your monitoring database be manipulated by a potentially malicious AI agent? Like, if the AI agent has full reign over the DB and it can't find a solution to, let's say, a perf bug, it may just rewrite that data and say it has "solved" the bug. And this is literally the least concerning example I could come up with.
Most of MCP servers and Apps are way under-designed today. A lot of MCP B2B servers still wrap legacy APIs, and most MCP Apps try to reproduce a website experience instead of trying to reinvent the experience from scratch.
It feels like we're in the early mobile years where companies have not figured out what to do with this new technology. I hope the Uber and Candy Crushes of the AI era will land in 2026! (well maybe not candy crush, but some IA native games would be nice)
why can't this be a cli tool? then you can get an agent to write a script that programmatically calls the cli tool in addition to the agent calling it directly.
It could be a cli tool, and it should be a cli tool, for exactly this reason.
Let the LLM work in code mode. Don't make it have to be the execution engine too. It can do it but it's slow and giving it tools script what it wants will go far better.
I do think there's an interesting possibility where we turn MCP into something composable. Capnproto has promise pipelining where you can issue new instructions with results you don't have yet. If MCP could copy those tricks, & express promises... and those promises worked across MCP servers ("third party handoff", https://github.com/capnproto/go-capnp/issues/597)... you'd start to have something as compellingly composable as the shell.
The prompt injection via telemetry point is sharp. Same class of problem shows up whenever an agent reads structured data from an untrusted source — contract ABIs, API responses, even config files.
Observability is a good forcing function for thinking about this!(at least tracepoint data has a known schema. Unstructured sources are worse)
14 comments
[ 0.14 ms ] story [ 38.0 ms ] threadIt feels like we're in the early mobile years where companies have not figured out what to do with this new technology. I hope the Uber and Candy Crushes of the AI era will land in 2026! (well maybe not candy crush, but some IA native games would be nice)
Let the LLM work in code mode. Don't make it have to be the execution engine too. It can do it but it's slow and giving it tools script what it wants will go far better.
I do think there's an interesting possibility where we turn MCP into something composable. Capnproto has promise pipelining where you can issue new instructions with results you don't have yet. If MCP could copy those tricks, & express promises... and those promises worked across MCP servers ("third party handoff", https://github.com/capnproto/go-capnp/issues/597)... you'd start to have something as compellingly composable as the shell.
Observability is a good forcing function for thinking about this!(at least tracepoint data has a known schema. Unstructured sources are worse)