Use SigNoz with Sazabi: query logs, traces and alerts over MCP

Last verified on Nov 8, 2026.

SigNoz keeps logs, traces and metrics together, and it exposes them through its own MCP server. Sazabi, the AI-native observability and security platform, connects its agent to that server, so a question in a Sazabi thread can pull SigNoz evidence without leaving the thread.

What the Sazabi agent can do with SigNoz

Authentication is a SigNoz API key. Sazabi stores it and sends it as the SIGNOZ-API-KEY header. The default server URL targets SigNoz Cloud's US region, https://mcp.us.signoz.cloud/mcp. SigNoz documents the general form as https://mcp.<region>.signoz.cloud/mcp, and self-hosted setups use their own endpoint. With that connection the agent can:

• list and query metrics, and discover field keys and values
• search traces and surface top metrics
• inspect alerts and notification channels
• create alerts, notification channels and dashboards, unless the connection is read-only

SigNoz names the tools, which makes questions precise. signoz_search_logs and signoz_aggregate_logs cover logs, where aggregation takes Query Builder expressions such as count() and p99(duration). signoz_search_traces, signoz_aggregate_traces and signoz_get_trace_details cover traces. signoz_list_alerts shows firing, silenced or inhibited instances, and signoz_get_alert_history gives a rule's firing history. signoz_check_metric_cardinality lists a metric's label keys with cardinality counts.

Questions it answers

• Which services logged the most errors in the last 30 minutes?
• What is the full trace for this trace ID?
• Which alert rules fired today, and how often did each one change state?
• Which dashboards and alerts reference this metric before we rename it?
• Which label on this metric has the highest cardinality?

A worked example: checking whether an alert rule is noisy

A teammate wants to retire an alert for the payments service. Rather than guess, you ask in a thread:

List the SigNoz alert rules whose name contains "payments". For each one,
show its firing and state-transition history for the last week, and tell me
which ones changed state more than ten times.

The agent can call signoz_list_alert_rules, which filters by name, label, severity or state, then signoz_get_alert_history for each rule. SigNoz describes that history as firing and state-transition events, cursor-paginated, so a long history comes back in pages and the agent has to keep paging. A rule that flips every few minutes is a threshold problem. A rule that never fires may be covering nothing, or may be healthy, and the way to tell is to look at the signal behind it.

For that, signoz_check_metric_usage takes up to 50 metric names per call and returns which dashboards and alerts reference each one, so you can see what breaks before you drop a metric. If you decide to change the rule, the agent can use signoz_update_alert, but only when the connection is not read-only and the API key is admin-level. For a first investigation, turn the read-only toggle on and keep it on.

If no tools appear after you connect, the Sazabi docs point to two causes: an API key that is invalid, or a server URL that does not match your SigNoz instance. Re-enter both. On a self-hosted instance that returns 404 for a tool, check the SigNoz and MCP server release first, because each MCP release targets the latest SigNoz.

How it fits with other integrations

SigNoz sits next to Honeycomb, Grafana and Axiom as a stack the Sazabi agent can query. Your own services can send logs and traces to Sazabi over OpenTelemetry. See the observability tools category for the full list, or pricing for plan details.