Introduction

Most observability dashboards have built-in agents these days, and that agent can piece together answers or make changes to the interface. But these built-in agents are isolated from your repo, skills, and context.

Clear solves this by making observability visible and malleable to your coding agent. With WebMCP, humans and agents can triage issues, build dashboards, and understand incidents. Setting up Clear is as simple as pointing any* OpenTelemetry (OTel) client at our endpoints.

What it does

Services send metrics, logs, and traces to Clear, and users can use their agent to set thresholds that fire alerts or build custom dashboards.

When an alert fires, a user or an agent can open an incident. The agent can query telemetry from Clear and create panels within the dashboard to test hypotheses. Users steer the agent in a particular direction, ask questions about the data, and work toward a patch.

WebMCP enables this by allowing any WebMCP-capable agent to instantly access dashboards and logs without traditional MCP auth flows.

How I built it

I built Clear by creating a handful of different services:

  • Backend hosted on Render
    • API service
    • Postgres database for non-telemetry data
    • ClickHouse database for logs, metrics, and traces
    • Go OTel Collector
  • Simple React frontend hosted on ChatGPT Sites/Cloudflare

This work was done with AI assistance while I still guided the architecture decisions and product experience.

Challenges we ran into

The biggest challenge I overcame was collecting the OTel data and streaming it live to the client. This project started out as a fully TypeScript project, but there weren’t any good TypeScript libraries that acted as a complete OTel receiver. Rather than implementing this receiver myself, I built a small Go service that accepts and authenticates OTel traffic and forwards batches to the API service. The API service then normalizes and stores that data in ClickHouse. It also streams live events to the client using Server-Sent Events (SSE, basically a one-way WebSocket). Unfortunately, Render does not support external gRPC, so we are only able to support HTTP with JSON and Protobuf.

Another challenge I ran into was synchronizing the dashboard across clients while keeping it legible to agents. On the server, we store a revision ID so that when an agent attempts to update a dashboard based on a stale version, the agent is asked to try again with the latest dashboard. We then use SSE to propagate changes across clients, and have some additional logic to resync clients that missed updates.

Accomplishments that I'm proud of

I'm proud of the fact that I was able to build a working OTel ingestion service and dashboard. WebMCP is the icing on the cake and what makes this project interesting, but a usable OTel dashboard is the table stakes. Without that, this entire project wouldn't have been possible.

I'm also proud of the fact that Clear WebMCP is 3 times faster with smaller queries, and (anecdotally) much preferred by agents for its simple interface compared to the Grafana MCP server. While WebMCP enables this human-in-the-loop problem-solving, rebuilding the platform with agents in mind means streamlined tools and better AX (Agentic eXperience).

What I learned

While this project only represents one potential use of WebMCP, the potential for use across many different products is infinite. Being able to pull up a website in my browser and ask my agent a question about it is powerful in so many ways and feels like the next evolution of computer use. After starting this hackathon, I genuinely found myself wishing certain websites that I use had WebMCP.

What's next for Clear

Clear is very much a small vertical slice of this project rather than an enterprise-ready, drop-in Grafana replacement. I hope to refine this project in the future by fixing some issues so it can scale more easily, as well as improving the UI and UX.

*Any OTel client that supports HTTP exports. We do not support gRPC.

Built With

Share this project:

Updates