“Read-token traces turned Logfire into my agent debugging loop”
I'm a builder, and the honest truth about observability tools is that I install them and then never open the dashboard. Logfire broke that pattern for me, but not because of anything I clicked in the UI — it was because I wired logfire-mcp into several of my projects and made the traces queryable from my agent instead. Concretely: I added logfire-mcp to my .claude.json across a handful of projects, each scoped with a read-only token via LOGFIRE_READ_TOKEN so the agent can pull data but can't touch anything. Then I built a /logfire skill on top of its query API with the four operations I actually reach for when something breaks: list recent errors, find slow requests, pull recent spans, and look up a single trace by id. That's the whole surface I needed, and it maps cleanly onto how I debug. The result is that observability finally became part of my loop instead of a tab I forget exists. When a backend endpoint misbehaves, I don't go context-switch into a dashboard and start clicking around filters. I ask the agent, it calls the skill, and the recent exceptions and the slowest traces come straight back into the conversation where I'm already working. From there I can grab a specific trace id and pull that one span tree to see exactly where the latency or the error lives. The read token keeps me honest — it's query-only, so I never worry that a debugging session is going to mutate state. What I appreciate is how little ceremony this took. The query API was straightforward enough that wrapping it in a skill — recent errors, slow requests, recent spans, trace-by-id — was a short job, and the read-only token model made it safe to drop into multiple repos without overthinking permissions. The payoff is real: having traces and backend exceptions reachable from the agent is the single thing that got me to actually use observability day to day, rather than treating it as something I'd consult only during an incident. Four stars rather than five because my praise here is really about the queryable surface and the read-token story fitting my agent-first workflow — that's the slice I've leaned on, and it's earned. I haven't put the rest of the product through enough to vouch for it the same way. But on the specific thing I built — read-token traces feeding a tight debugging loop where exceptions and slow requests show up without me leaving my editor — it delivered, and it changed a habit I'd basically given up on.
- No comments yet.