Discussion

MCP as Observability Interface: Connecting AI Agents to Kernel Tracepoints

Eldodi: 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)

hrimfaxi: 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.

gcifuentes: Couldn't you create a MCP eBPF module and dynamically generate probe points?

chaoz_: 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).

Vunovati: I've built something similar to what you described: https://kopai.appOTEL 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.

sharts: Real friends don’t let friends MCP

weavie: Why?