other
Most observability tools make you learn a query language before you can answer a simple question like "why is checkout slow." groundcover's MCP server skips that step: it hands your agent direct access to the metrics, logs, and traces groundcover already collects via its eBPF-based instrumentation, so you can ask about error rates, latency, or resource usage for a specific service in plain English. Because the instrumentation is eBPF-based, none of this depends on you having added tracing libraries to the service in question — groundcover is already watching at the kernel level.
| groundcover MCP server | groundcover lets you query metrics, logs, and traces collected via eBPF-based instrumentation across your cloud-native or on-prem environments. You can ask about error rates, latency, or resource usage for a specific service without instrumenting your code. |
Ask "why did the payments service get slower in the last hour" and the agent pulls groundcover's traces and metrics for that service, correlates them with any error-rate change, and reports back what's likely responsible — no dashboard hunting.
Before bumping a service's replica count, ask the agent to pull current CPU and memory usage from groundcover so the decision is based on real numbers instead of a guess.
No — groundcover instruments at the eBPF level, so it already has metrics, logs, and traces for services running in your cloud-native or on-prem environment without code changes.
Anything grounded in what groundcover tracks for a given service — error rates, latency, and resource usage are the core signals it exposes through this connection.