MCP
Your agent is already in the code. Give it the logs.
When something breaks, the assistant you are already talking to has to be handed a screenshot. Connect it to Bilis instead and it reads the errors itself: which lines failed, how often, and the whole request that produced them — while it is looking at the code that produced it. One line to connect, and no key to paste.
Swap the host for your own instance. Self-hosted Bilis is free and has no plan; the server is part of the app, with nothing extra to run.
01 What changes
From "it's broken" to the failing span, without leaving the chat.
The agent asks Bilis the questions you would have asked it yourself, in the order you would have asked them.
-
"Checkout has been 500ing since the deploy."
Groups the last hour's errors into distinct problems and names the one that started when the deploy did — with a count, not a wall of duplicate lines.
error-summary
-
"Show me one of those requests."
Opens the whole request as a waterfall: every service it touched, how long each step took, and which one failed first.
get-trace
-
"Was it slow before that too?"
Reads p95 and p99 per service over whatever window you name, so a regression is a number rather than a feeling.
service-latency
-
"What was the app logging just before it?"
Reads the lines around the failure in order — usually more informative than the failure itself.
search-logs
02 Where the line is
It can read. That is all it can do.
Handing an agent a credential to your observability stack is a real decision, so the answer is not "trust the prompt". The connection is read-only at the server: there is no tool that writes, and none that could be talked into it.
You sign in yourself, in your own browser, and approve the connection on a screen that names the client. Access lasts a day and refreshes for a month while the client keeps using it. No API key is ever copied, shown to the agent, or created by it.
And the data stays where it was: your instance answers the questions, so the logs never travel anywhere they were not already.
- Search logs and read traces for the teams you belong to
- List your teams, projects and the services they send
- Send, edit or delete anything
- Create a project, or read or issue an API key
- Change a setting, or start an Autofix job
03 The toolbox
Eight tools, two prompts, no surprises.
- list-teams
- The teams you belong to, and which one the tools default to.
- list-projects
- A team's projects, and whether each has ever received anything.
- list-services
- The service names a project actually sends, so a filter is never a guess.
- search-logs
- Log lines over a window, by service, severity, text, trace or span.
- error-summary
- A window's errors folded into distinct problems, with counts.
- list-traces
- Traces over a window: duration, span count, error count.
- get-trace
- One request as a waterfall, with the attributes that locate a bug.
- service-latency
- p95 and p99 per service, slowest first.
Plus two prompts your client can pull in: one that teaches a fresh assistant how to wire an app up to send here, and one that turns a reported symptom into a plan across the tools above.
Connect it and ask it something.
The guide has the exact configuration for every client, and what to set when you are running Bilis yourself.