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)
Every week these model providers are coming out with new toys. I don't fault orgs for minimally investing in MCP when the space is moving so fast and there's no telling whether or not MCP is here to stay.
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.
@neil_naveen The read-only mode wongarsu mentions closes the direct modification vector, but there's a subtler one not addressed: prompt injection via the telemetry itself. If the MCP server traces arbitrary workloads, a malicious process can craft CUDA kernel names, string arguments, or function identifiers that produce adversarial text in the trace DB. The LLM reads those verbatim as part of its context and may follow embedded instructions.
This is indirect prompt injection through the observation channel rather than through user input. Read-only access and invocation logging both assume the threat arrives from outside the pipeline. When the observed data itself is the attack surface, you need output sanitization or context sandboxing before telemetry reaches the model. Multi-tenant or production environments where the MCP server traces workloads from multiple teams would be particularly exposed.
Maybe they have limited the MCP endpoint to reject any query that modifies the db. With sqlite that's probably easily achieved by opening the db in read-only mode (as opposed to the role-based approach you'd take with most other dbs)
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.
You absolutely could. It'd be cool (not easy from security/compliance perspective) to be able to deeply "scan" your prod-deployed app.
There are a quite a few startups created by connecting relevant eBPF/OTel traces e.g. in response to uncaught exceptions (traditional RAG-based bug-fix generation).
I've built something similar to what you described: https://kopai.app
OTEL is the common denominator for all the observability purposes including the ones that come from eBPF and the application layer.
Same architectural idea as Ingero. We skip the aggregation layer. We also skip the MCP part. The agent uses a CLI instead, which keeps it composable with any coding agent workflow.
You can have your claude poke at the logs/metrics/traces using a dedicated cli tool paired with some agent skills. It is Apache-licensed and you can try it locally.
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)
Every week these model providers are coming out with new toys. I don't fault orgs for minimally investing in MCP when the space is moving so fast and there's no telling whether or not MCP is here to stay.
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.
@neil_naveen The read-only mode wongarsu mentions closes the direct modification vector, but there's a subtler one not addressed: prompt injection via the telemetry itself. If the MCP server traces arbitrary workloads, a malicious process can craft CUDA kernel names, string arguments, or function identifiers that produce adversarial text in the trace DB. The LLM reads those verbatim as part of its context and may follow embedded instructions.
This is indirect prompt injection through the observation channel rather than through user input. Read-only access and invocation logging both assume the threat arrives from outside the pipeline. When the observed data itself is the attack surface, you need output sanitization or context sandboxing before telemetry reaches the model. Multi-tenant or production environments where the MCP server traces workloads from multiple teams would be particularly exposed.
Maybe they have limited the MCP endpoint to reject any query that modifies the db. With sqlite that's probably easily achieved by opening the db in read-only mode (as opposed to the role-based approach you'd take with most other dbs)
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.
Couldn't you create a MCP eBPF module and dynamically generate probe points?
You absolutely could. It'd be cool (not easy from security/compliance perspective) to be able to deeply "scan" your prod-deployed app.
There are a quite a few startups created by connecting relevant eBPF/OTel traces e.g. in response to uncaught exceptions (traditional RAG-based bug-fix generation).
I've built something similar to what you described: https://kopai.app
OTEL is the common denominator for all the observability purposes including the ones that come from eBPF and the application layer.
Same architectural idea as Ingero. We skip the aggregation layer. We also skip the MCP part. The agent uses a CLI instead, which keeps it composable with any coding agent workflow.
You can have your claude poke at the logs/metrics/traces using a dedicated cli tool paired with some agent skills. It is Apache-licensed and you can try it locally.
We no longer need dashboards, just connect ChatGPT to a metrics database or whatever.
[dead]
[dead]
[dead]
Real friends don’t let friends MCP
Why?