SigNoz MCP Server

The SigNoz MCP Server is SigNoz’s official Model Context Protocol server for observability work with AI agents. It connects MCP-capable clients to a SigNoz instance and exposes metrics, logs, traces, alerts, dashboards, services, and official documentation as tools. The direct product link leads to the official SigNoz documentation; source code, installation details, and the license are in the SigNoz/signoz-mcp-server repository. SigNoz therefore operates both the product and the repository. DevOps and Data Analysis are precise categories: teams inspect operational state, error rates, and latency, analyse telemetry, and turn that evidence into reviewable next steps.

Cloud and self-hosting are different paths

The deployment type is both, not exclusively remote or local. According to the official documentation, SigNoz Cloud connects without installation through the hosted endpoint https://mcp.<region>.signoz.cloud/mcp; the client then starts authentication. For a self-hosted SigNoz instance, the official README instead documents a local binary, Go installation, Docker image, or source build. That local variant can run through stdio directly from an AI client or as an independently operated HTTP service. When using HTTP, explicitly bind the host to 127.0.0.1 when external access is unnecessary: the README otherwise lists all interfaces as the default. Operating a public HTTP endpoint also requires careful OAuth and network configuration.

What the server can query

The read tools cover common incident and analysis workflows. They include discovering active metrics, time-series and aggregate queries, cardinality analysis, log search and aggregation, trace search, full trace details, services and their operations, currently firing alerts, and alert histories. Dashboards and saved Explorer views can be read. This is useful when a team first narrows down unusual services and error trends, then checks logs and traces in the appropriate time window, and evaluates the result against a specific hypothesis. Results are not automatic root-cause analysis, however: time range, filters, telemetry quality, and data completeness still require subject-matter review.

Write tools and destructive consequences

The scope goes beyond reading. According to the README, the server can create, fully update, or delete alert rules, dashboards, saved views, and notification channels. Delete operations for alerts, dashboards, views, and notification channels are permanent. Creating or updating a notification channel may also send a test notification. Some delete tools document confirmation of the exact object, but that safeguard does not replace a team approval process. For production, use a separate account or service account with least privilege, a read-only client for analysis, and human review before every change. Agents must not treat untrusted log lines, trace attributes, or documentation text as instructions to act on: such content can contain prompt injection.

Authentication, tokens, and sensitive telemetry

SigNoz Cloud uses an authenticated client flow. The official documentation identifies the instance URL and an API key from Service Accounts; only administrators can create such keys. For clients without interactive OAuth, keys may be placed in headers. The provider explicitly warns not to commit configuration files containing secrets. Self-hosted setups use SIGNOZ_URL and SIGNOZ_API_KEY as environment variables or, in an HTTP client configuration, headers. Tokens belong in secret stores or local unversioned configuration and need rotation and revocation when exposure is suspected.

Observability data can be highly sensitive: log bodies, SQL fragments, URLs, user identifiers, trace attributes, host names, and incident context can contain personal, business, or credential information. Telemetry data minimisation, redaction before ingestion, short query windows, and restrictive SigNoz roles reduce exposure. The MCP server is only a bridge. Depending on the chosen AI client, tool results, prompts, or context may be sent to that client’s model provider. A locally operated MCP binary therefore does not automatically make the entire LLM path local. Privacy, data-processing agreements, and model/client settings require separate review.

License, costs, and popularity signal

The repository is Apache-2.0 licensed; the LICENSE file is the authoritative license source. The server can be operated locally as open source, while SigNoz Cloud, an organisation’s own infrastructure, and the selected AI client each have their own usage and cost terms. This entry intentionally states no fixed prices. The GitHub API reported exactly 118 stars for this specific repository on 2026-09-08, immediately before seeding. That number is only a point-in-time popularity signal, not evidence of quality, security, or suitability.

FAQ

Is SigNoz MCP only for SigNoz Cloud? No. Cloud uses the hosted regional MCP endpoint; self-hosted installations can use the official binary, Go, Docker, or a source build. That is why this entry is classified as both.

Can I safely connect it to production data? Not categorically. Start with minimal permissions, read-only queries, and redacted telemetry. Also examine the AI client’s data path to its model provider before production logs or traces enter a prompt.

SigNoz Cloud or a self-hosted SigNoz instance, an MCP-capable client such as Claude Code, Codex, or Cursor, and an API key or OAuth access with least privilege.

Cloud: add the regional endpoint https://mcp.<region>.signoz.cloud/mcp to the client and authenticate. Self-hosted: use the official binary, Go, Docker, or source build; set SIGNOZ_URL and SIGNOZ_API_KEY as secrets for stdio.

codex mcp add signoz --url https://mcp.<region>.signoz.cloud/mcp

Cloud through the client authentication flow with instance URL and service-account API key; self-hosted through an API key, with optional OAuth in HTTP mode.

An API key or OAuth access can enable read and write SigNoz operations. Use least privilege, separate production accounts, and human approval before changes.

The server sends tool requests to SigNoz and returns telemetry results to the MCP client. Depending on the client, results and prompt context can then reach its model provider.

API keys, sensitive logs and traces, prompt injection in observability content, and irreversible delete and write tools for alerts, dashboards, views, and notification channels.