Query Honeycomb datasets, boards and SLOs from Sazabi

Last verified on Nov 8, 2026.

Honeycomb is where many teams keep high-cardinality event and trace data. The Sazabi agent, part of Sazabi's AI-native observability and security platform, can query it from the same thread where you debug an incident, so you do not have to switch tabs and re-type the question.

What the Sazabi agent can do with Honeycomb

The connector uses Honeycomb's own MCP server. It authenticates with OAuth and dynamic client registration, with separate endpoints for the US and EU. Once connected, the agent can:

• list environments and datasets, and inspect columns
• run queries and read their results
• view boards, triggers and SLOs
• create and update boards and triggers
• pull trace and event context into a thread

Honeycomb's tool reference groups these by job. get_environment, get_dataset and get_dataset_columns orient the agent. run_query computes aggregations with breakdowns and formulas, and find_columns finds fields by intent instead of exact name. run_bubbleup compares a selected subset against the baseline. get_trace returns every span for a trace ID. get_triggers and get_slos read alerting setup, and create_trigger writes one.

Most Honeycomb tools are read-only. Tools for boards, triggers, SLOs, notification recipients and Canvas investigations need a scope for that resource, which you grant during OAuth consent. In Sazabi's connector setup, write tools need the mcp:write scope on top of Read access under Model Context Protocol.

Questions it answers

• What does p99 of request duration look like by endpoint for the last hour?
• Which column values separate the slow requests from the rest?
• What is in this trace, and which span carries the error?
• Which triggers watch this dataset, and when did they last fire?
• How much error budget does the checkout SLO have left?

A worked example: from a slow query to the column that explains it

A trigger on API latency fires. In a Sazabi thread you ask:

In the production environment, find the dataset for the api service. Run a query
for p99 of duration_ms grouped by http.route over the last two hours. Then run
BubbleUp on the slowest route and tell me which columns differ from the baseline.

The agent starts with discovery: get_environment for the production environment, get_dataset for the right dataset, and find_columns to map "duration" and "route" onto real column names, because it does not need exact names to search. It then calls run_query with a percentile calculation and a breakdown by route. When one route stands out, run_bubbleup runs on that result, and Honeycomb's reference says it compares value distributions across columns and surfaces the statistically significant differences.

Read the output as a lead, not a verdict. If BubbleUp points at one customer ID, one region or one build, the next question is whether it started with a deploy, so ask the agent to open a trace from that value with get_trace and compare it with the timeline of the deploy. If the differences are scattered, the cause is probably load, and the useful move is to check the SLO state with get_slos. When you want to keep the query, ask for a board or trigger. That uses the write tools, so it only works if you granted mcp:write.

How it fits with other integrations

Honeycomb is one of several stacks Sazabi can query next to its own data. The SigNoz and Grafana pages cover two others, and Pydantic Logfire covers a SQL-based one. All of them sit in the observability tools category. Services you instrument yourself can send to Sazabi through OpenTelemetry, and the integrations index lists every method.