Signoz MCP Server

SigNoz MCP Server

A Model Context Protocol (MCP) server that provides seamless access to SigNoz observability data through AI assistants and LLMs. Query metrics, traces, logs, alerts, dashboards, and services using natural language.

📖 Full Documentation

Table of Contents

• Connect to SigNoz Cloud
• Self-Hosted Installation
• Connect to Self-Hosted SigNoz
• MCP Protocol Compatibility
• What Can You Do With It?
• Available Tools
• Environment Variables
• Claude Desktop Extension
• End-to-End Tests
• Architecture
• Contributing

Connect to SigNoz Cloud

Connect your AI tool to SigNoz Cloud's hosted MCP server. No installation is required; just add the hosted MCP URL and authenticate.

https://mcp.<region>.signoz.cloud/mcp

Make sure you select the correct region that matches your SigNoz Cloud account. Using the wrong region will result in authentication failures.

Find your region under Settings → Ingestion in SigNoz, or see the SigNoz Cloud region reference.

One-Click Install Links

GitHub does not reliably make custom-protocol links like cursor:// and vscode: clickable in README rendering.

Use the documentation page for one-click install buttons:

• Open one-click install links for Cursor
• Open one-click install links for VS Code

If you prefer, use the manual configuration examples below in this README.

Cursor

Manual Configuration

Add this configuration to .cursor/mcp.json:

{
  "mcpServers": {
    "signoz": {
      "url": "https://mcp.<region>.signoz.cloud/mcp"
    }
  }
}

Need help? See the Cursor MCP docs.

VS Code / GitHub Copilot

Manual Configuration

Add this configuration to .vscode/mcp.json:

{
  "servers": {
    "signoz": {
      "type": "http",
      "url": "https://mcp.<region>.signoz.cloud/mcp"
    }
  }
}

Need help? See the VS Code MCP docs.

Claude Desktop

Add SigNoz Cloud as a custom connector in Claude Desktop:

1. Open Claude Desktop.
2. Go to Settings → Developer (or Features, depending on your version).
3. Click Add Custom Connector or Add Remote MCP Server.
4. Enter your SigNoz MCP URL: https://mcp.<region>.signoz.cloud/mcp

When prompted, complete the authentication flow.

Claude Code

Run this command to add the hosted SigNoz MCP server:

claude mcp add --scope user --transport http signoz https://mcp.<region>.signoz.cloud/mcp

After configuring the MCP server, authenticate in a terminal:

claude /mcp

Select the signoz server and complete the authentication flow.

OpenAI Codex

Run this command to add the hosted SigNoz MCP server:

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

Or add this configuration to config.toml:

[mcp_servers.signoz]
url = "https://mcp.<region>.signoz.cloud/mcp"

After adding the server, authenticate:

codex mcp login signoz

Then run /mcp inside Codex to verify the connection.

Grok Build

Run this command to add the hosted SigNoz MCP server:

grok mcp add -t http signoz https://mcp.<region>.signoz.cloud/mcp

Or add this configuration to ~/.grok/config.toml:

[mcp_servers.signoz]
url = "https://mcp.<region>.signoz.cloud/mcp"
enabled = true

Adding the server does not authenticate it. Start Grok Build, run /mcps, select the signoz server, and complete the OAuth flow in your browser:

grok

/mcps

No API key is stored in the config file; credentials are saved separately once the OAuth flow completes.

Use -s project on the add command to write to ./.grok/config.toml instead, so the server is shared with everyone working in that directory.

Verify the connection with:

grok mcp list
grok mcp doctor

SigNoz Cloud Authentication

When you add the hosted MCP URL to your client, the client initiates an authentication flow. You will be prompted to enter:

1. Your SigNoz instance URL (for example, your-instance.signoz.cloud). Protocol-less URLs are accepted; paths, query parameters, and fragments are ignored.
2. Your API key

Create an API key in Settings → API Keys in SigNoz. Only Admin users can create API keys.

Self-Hosted Installation

Download Binary (Recommended)

Download the latest binary from GitHub Releases:

# macOS (Apple Silicon)
curl -L https://github.com/SigNoz/signoz-mcp-server/releases/latest/download/signoz-mcp-server_darwin_arm64.tar.gz | tar xz

# macOS (Intel)
curl -L https://github.com/SigNoz/signoz-mcp-server/releases/latest/download/signoz-mcp-server_darwin_amd64.tar.gz | tar xz

# Linux (amd64)
curl -L https://github.com/SigNoz/signoz-mcp-server/releases/latest/download/signoz-mcp-server_linux_amd64.tar.gz | tar xz

This extracts a signoz-mcp-server binary in the current directory. Move it somewhere on your PATH or note the absolute path for the config below.

Go Install

go install github.com/SigNoz/signoz-mcp-server/cmd/server@latest

The binary is installed as server to $GOPATH/bin/ (default: $HOME/go/bin/server). You may want to rename it:

mv "$(go env GOPATH)/bin/server" "$(go env GOPATH)/bin/signoz-mcp-server"

Docker

Docker images are available on Docker Hub:

docker pull signoz/signoz-mcp-server:latest

Run in HTTP mode:

docker run -p 8000:8000 \
  -e TRANSPORT_MODE=http \
  -e MCP_SERVER_PORT=8000 \
  -e SIGNOZ_URL=https://your-signoz-instance.com \
  -e SIGNOZ_API_KEY=your-api-key \
  signoz/signoz-mcp-server:latest

Use a specific version tag (e.g. v0.1.0) instead of latest for pinned deployments.

Build from Source

git clone https://github.com/SigNoz/signoz-mcp-server.git
cd signoz-mcp-server
make build

The binary is at ./bin/signoz-mcp-server.

Connect to Self-Hosted SigNoz

Prerequisites

• A running SigNoz instance on the latest release. Each server release targets the latest SigNoz release and is not tested against older versions; see CHANGELOG.md for breaking changes.
• A SigNoz API key (Settings → API Keys in the SigNoz UI)
• The signoz-mcp-server binary (see Self-Hosted Installation)

Stdio Mode (Claude Desktop / Cursor / Any MCP Client)

Add this to your MCP client config (claude_desktop_config.json, .cursor/mcp.json, etc.). Replace the command path with the absolute path to your signoz-mcp-server binary:

{
    "mcpServers": {
        "signoz": {
            "command": "/absolute/path/to/signoz-mcp-server",
            "args": [],
            "env": {
                "SIGNOZ_URL": "https://your-signoz-instance.com",
                "SIGNOZ_API_KEY": "your-api-key-here",
                "LOG_LEVEL": "info"
            }
        }
    }
}

HTTP Mode

HTTP mode listens on all interfaces by default. Set MCP_SERVER_HOST=127.0.0.1 when the server should accept loopback connections only.

Memory footprint

The server keeps the SigNoz docs search index in memory. With stemming on titles and headings and a single standard-analyzed body field, the embedded 746-page index used 28 to 36 MiB of resident heap across eight local Go 1.26 whole-package test runs. Build peaks ranged from 97 to 134 MiB above the pre-build heap baseline, using 64-page batches. These are index measurements, not whole-process RSS or container memory guarantees; request handling and refresh work add memory.

A scheduled refresh (default every 6h) first compares the live sitemap with the served one and stops there when it is unchanged. Otherwise it revalidates every page with If-None-Match and touches the index only when at least one page's content changed. A change set covering up to a quarter of the pages is applied to the live index in place; a larger one, the 25th in-place update on the same index, and any forced refresh (default every 24h) that finds changed content rebuild the index from scratch, which also compacts the segments that in-place updates leave behind. Full rebuilds use 64-page batches. In-place updates use one atomic batch bounded by the quarter-of-pages threshold, not the full-build batch size.

Recommendations for containerized HTTP deployments:

• Set the memory limit to at least 512Mi, and monitor memory during refreshes and concurrent requests. The highest measured index-only build peak is 134 MiB above baseline and the resident index is 28 to 36 MiB; rebuilds also retain the serving index. Setting Go's GOMEMLIMIT is optional: it can reclaim garbage earlier but cannot shrink live data inside an index batch.
• Set both SIGNOZ_DOCS_REFRESH_INTERVAL=0 and SIGNOZ_DOCS_FULL_REFRESH_INTERVAL=0 when you would rather serve the docs snapshot that shipped with the release than pay any refresh. New docs pages then arrive with the next server upgrade. Setting only the first keeps the daily forced refresh.
• Every refresh logs docs refresh starting and ends with a completion or failure line, for example docs refresh no-op; sitemap unchanged, docs refresh found no page changes; index kept, docs refresh applied delta, docs refresh rebuilt index, or a docs refresh failed / docs full refresh failed warning. A refresh normally finishes within a few minutes. A container whose last docs line is docs refresh starting, docs refresh fetching pages, or docs refresh rebuilding index and that then restarted most likely died mid-refresh.

With OAuth (Multi-Tenant / Cloud)

Start the server:

TRANSPORT_MODE=http \
MCP_SERVER_PORT=8000 \
OAUTH_ENABLED=true \
OAUTH_TOKEN_SECRET=$(openssl rand -base64 32) \
OAUTH_ISSUER_URL=https://your-public-mcp-url.com \
./signoz-mcp-server

Client config needs just the URL, no keys:

{
    "mcpServers": {
        "signoz": {
            "url": "https://your-public-mcp-url.com/mcp"
        }
    }
}

The client discovers OAuth endpoints automatically, opens a browser for credentials, and handles token exchange.

Without OAuth (Simple Setup)

The API key and SigNoz URL only need to be provided in one place: the server or the client.

Option A — Credentials on the server (simpler client config):

SIGNOZ_URL=https://your-signoz-instance.com \
SIGNOZ_API_KEY=your-api-key \
TRANSPORT_MODE=http \
MCP_SERVER_PORT=8000 \
./signoz-mcp-server

{
    "mcpServers": {
        "signoz": {
            "url": "http://localhost:8000/mcp"
        }
    }
}

Option B — API key on the client (server holds the URL, client sends the key):

SIGNOZ_URL=https://your-signoz-instance.com \
TRANSPORT_MODE=http \
MCP_SERVER_PORT=8000 \
./signoz-mcp-server

{
    "mcpServers": {
        "signoz": {
            "url": "http://localhost:8000/mcp",
            "headers": {
                "SIGNOZ-API-KEY": "your-api-key-here"
            }
        }
    }
}

MCP Protocol Compatibility

SigNoz uses the official MCP Go SDK v1.8.0 and supports both current lifecycle models over HTTP and stdio:

The HTTP /mcp endpoint is stateless and sessionless. MCP messages use JSON POST requests and successful responses use application/json; the server does not issue or require Mcp-Session-Id. GET /mcp and DELETE /mcp return 405 Method Not Allowed, so deployments need neither sticky routing nor the old GET listener/heartbeat. Existing client configuration does not change.

Stdio input has a 16 MiB frame limit. Split larger requests into smaller calls. MCP_MAX_REQUEST_BYTES controls HTTP request bodies only.

The server intentionally does not advertise the deprecated logging capability. Discovery ordering is not a compatibility guarantee. Unknown tools, resources, and prompts use the official SDK's standard invalid-params behavior rather than legacy implementation-specific wording or error codes.

HTTP Probe Endpoints

HTTP mode exposes unauthenticated probe endpoints. New Kubernetes deployments should use /livez for livenessProbe and /readyz for readinessProbe.

What Can You Do With It?

"Show me all available metrics"
"What's the p99 latency for http_request_duration_seconds?"
"List all active alerts"
"Show me error logs for the paymentservice from the last hour"
"How many errors per service in the last hour?"
"Search traces for the checkout service from the last hour"
"Get details for trace ID abc123"
"Create a dashboard with CPU and memory widgets"
"How do I send Docker logs to SigNoz?"

Available Tools

Tool metadata: every tool accepts searchContext. Copy the user's entire original request verbatim, including preflight or confirmation context; it is used for MCP observability and is not forwarded to SigNoz APIs.

Input validation: calls are never rejected for schema mismatches. Arguments are validated against each tool's advertised schema; a mismatched call still runs best-effort, and the successful result carries a deterministic appended Input validation notice: naming the affected top-level parameter when it can be derived safely from the advertised schema. Complex root-only mismatches use a generic fallback. Mismatches are also counted in the mcp.tool.validation.mismatches metric.

Upstream errors: upstream SigNoz 401 and 403 tool failures carry a stable structured code (UNAUTHORIZED or PERMISSION_DENIED) and numeric status. Recognized SigNoz error envelopes may also include bounded upstreamURL, upstreamSuggestions, upstreamDetails ([{message, suggestions}]), and upstreamRetry ({delay} in nanoseconds); the same recovery guidance appears in agent-readable text. Unrecognized bodies use the local status-derived coded fallback instead of raw passthrough, and authorization failures still name the failed tool and immediate recovery action. This error-only addition does not change tool names, schemas or descriptions, success payloads, resources or templates, or prompts.

For detailed usage and examples, see the full documentation.

Resource deep links: the resource read tools (signoz_list_dashboards, signoz_get_dashboard, signoz_list_alerts, signoz_list_alert_rules, signoz_get_alert, signoz_list_services, signoz_search_traces, signoz_get_trace_details) and the dashboard write tools (signoz_create_dashboard, signoz_update_dashboard, signoz_patch_dashboard, signoz_import_dashboard) include a webUrl field when the request carries a SigNoz instance URL: an absolute deep link to the resource in the SigNoz web UI (per result row for signoz_search_traces). The MCP server discovers the browser base from each SigNoz backend's global.external_url. API requests keep using the request's backend URL. See Browser links for self-hosted SigNoz.

Agent Routing Guidance

Use signoz_search_docs for topical discovery when no exact documentation page is selected, then signoz_fetch_doc for the chosen page or heading. Use live data tools for tenant telemetry, alert state, dashboards, saved views, and notification channels.

Docs tools use the same authentication path as other MCP tools.

Available Resources

Resource Template Migration

The live signoz://dashboard/{id}/summary and signoz://alert/{id}/summary resource templates are retired. resources/templates/list now returns an empty catalog. Use signoz_get_dashboard for a dashboard definition. For the former alert summary, call signoz_get_alert, then signoz_get_alert_history; omit the time range for the same six-hour window and set limit: 10 and order: "desc" for the closest history result.

signoz_get_org_overview

Get the current status and overall posture of the SigNoz deployment before drilling into exact resources. data.sourceStats is the authoritative complete flat bag containing every key and value reported by the deployment stats endpoint, including current and future fields. Typed convenience projections cover telemetry freshness and volume, infrastructure presence, dashboards, alert rules and runtime, notification channels, saved views, log pipelines, cloud integrations, users, authentication, service accounts, roles, licensing, and configuration.

• Parameters: no task parameters; like every tool, it accepts non-required searchContext for MCP observability.
• Authoritative source: sourceStats preserves every successfully decoded entry from the upstream data object under its original dotted key. Use the grouped fields for convenient interpretation and sourceStats when exact backend coverage or a newly introduced field matters. Counts are deployment aggregates; use signoz_list_dashboards, signoz_list_alert_rules, signoz_list_notification_channels, or signoz_list_views for exact inventories; signoz_list_metrics for metric names; signoz_list_alerts for current alert instances; and signoz_search_logs, signoz_search_traces, or signoz_query_metrics for time-windowed or per-service data.
• Missing fields: a key absent from sourceStats was not reported by the upstream collector and must not be interpreted as zero. The endpoint can return a partial HTTP 200 when an individual collector fails. In typed projections, a missing group total produces available: false; a reported zero produces available: true. Expected missing or invalid projection fields set metadata.projectionPartial and add an incompleteGroups entry with affected output paths, reason, next action, and exact fallback tools where available. An invalid projection value is still retained unchanged in sourceStats and named in invalidProjectionFields.
• Cloud-integration completeness: cloudIntegrations.sourceAvailability reports whether both current AWS/Azure provider counts were reported. Each provider has its own dataAvailable; an absent provider count is never converted to zero. If neither provider is reported, source availability is unavailable without setting overall metadata.projectionPartial; this can mean cloud integrations are unsupported/edition-gated or both provider queries failed, so do not interpret it as “no cloud integrations configured.” If exactly one is reported, source availability is partial and the missing provider receives non-recursive recovery guidance. connectedAccounts means a non-removed account with an account ID and at least one agent report, not a recent check-in or proof that an integration service is enabled.
• Projection metadata: reportedStatCount is the number of authoritative entries in sourceStats; projectedStatCount counts entries also represented in typed groups; and unprojectedStatCount counts entries available only in sourceStats, including future fields. projectionPartial, incompleteGroups, and invalidProjectionFields describe only typed-projection gaps; they do not indicate data was removed from sourceStats or claim endpoint-wide completeness.

signoz_list_metrics

Discover metric names and catalog metadata such as type, temporality, unit, and monotonicity. Use signoz_query_metrics for values or trends. This list has a limit but no offset pagination.

• Parameters:
  • searchText (optional) - Filter metrics by name substring (e.g., 'cpu', 'memory')
  • limit (optional) - Maximum number of metrics to return (default: 50)
  • timeRange (optional) - Relative range: 30m, 1h, 6h, 24h, 7d (default: 1h; ignored when both start and end are provided)
  • start/end (optional) - Unix ms timestamps. When both are provided, they override timeRange.
  • source (optional) - Data-source filter. Use "meter" to list Cost Meter metrics, the usage/billing metrics SigNoz meters on (currently telemetry ingestion volume); omit for the default metrics store
  • Completeness note: the response appends a note reporting hasMore (inferred from returnedRows == limit) so a limit-truncated list is never mistaken for the full set; narrow with searchText for more specificity

signoz_query_metrics

Query a known metric for values, trends, breakdowns, or formulas. The tool applies metric-aware defaults and auto-fetches omitted metadata; call it directly when metricName is known. Use signoz_list_metrics only to discover a name or inspect catalog metadata.

• Parameters:
  • metricName (required) - Metric name to query
  • metricType (optional) - gauge, sum, histogram, exponential_histogram (auto-fetched if absent)
  • isMonotonic (optional) - Boolean (or the strings "true"/"false"); auto-fetched if absent. An invalid value is rejected rather than silently treated as false
  • temporality (optional) - cumulative, delta, unspecified (auto-fetched if absent)
  • timeAggregation (optional) - Aggregation over time (auto-defaulted by type)
  • spaceAggregation (optional) - Aggregation across dimensions (auto-defaulted by type)
  • groupBy (optional) - Comma-separated field names or an array. Resource context is inferred for k8s.*, container.*, host.*, cloud.*, deployment.*, process.*, service.*, telemetry.*, and os.*; other names use attribute context
  • filter (optional) - Filter expression
  • timeRange (optional) - Relative time range <number><unit> where unit is m/h/d (e.g. '30m', '1h', '6h', '7d'; default: '1h'; ignored when both start and end are provided)
  • start/end (optional) - Unix ms timestamps. When both are provided, they override timeRange.
  • stepInterval (optional) - Step in seconds (auto-calculated if omitted)
  • requestType (optional) - Response format. Enum: time_series (default), scalar. Unknown values are rejected.
  • reduceTo (optional) - For scalar: sum, count, avg, min, max, last, median
  • formula (optional) - Expression over named queries (e.g., "A / B * 100")
  • formulaQueries (optional) - Array or JSON-encoded array string of additional named metric queries for formula. Each object supports name, metricName, metricType, isMonotonic, temporality, timeAggregation, spaceAggregation, groupBy, and filter; name and metricName are required.
  • source (optional) - Data-source filter. Use "meter" to query Cost Meter data; omit for the default metrics store
  • Result bounds: standalone generated metric queries and formula results use limit: 100 with __result desc. Every query feeding a formula uses limit: 10000, because component limits are applied before formula evaluation and independent top-100 inputs can discard a high-ratio group. The response decisions note reports both bounds. Narrow the filters/grouping when formula-input cardinality can exceed 10000.
  • Key-not-found errors: a filter referencing a key absent from this workspace's metrics metadata fails with recovery guidance in the error text plus a machine-readable missingKeys array in the structured error content

signoz_get_top_metrics

Return top 100 metrics ranked by ingested sample volume with pre-computed percentages. Use this to identify which metrics are driving the most ingestion volume and cost. Wraps POST /api/v2/metrics/treemap. Response fields: metricName, percentage (share of total sample volume), totalValue (absolute sample count).

• Parameters:
  • timeRange (optional) - Relative time range <number><unit> where unit is m/h/d (e.g. '1h', '24h', '3d', '7d', '30d'; default: '7d'; ignored when both start and end are provided). Start with 7d; if the query times out, retry with 3d, then 24h
  • start/end (optional) - Unix ms timestamps. When both are provided, they override timeRange
  • Completeness note: returns a fixed top 100 by ingested sample volume; the response appends a note flagging whether the list was truncated at that cap (hasMore)

signoz_check_metric_usage

Given a list of metric names, return which dashboards and alerts reference each one. Wraps /api/v3/metrics/dashboards?metricName=... and /api/v2/metrics/alerts?metricName=... per metric.

• Parameters:
  • metricNames (required) - Array of metric name strings to check (max 50 per call). Example: ["system.disk.io", "k8s.node.condition"]. For larger lists, split into batches of 50 and merge results.
• Response: per metric, dashboards (list of dashboard names that reference the metric), alerts (list of alert names that reference the metric), error (non-empty when the lookup failed; do not treat the metric as unused in that case)
• Limits: Maximum 50 metrics per call; 30-second overall timeout (partial results returned on expiry)

signoz_check_metric_cardinality

Return label/attribute keys for one metric with cardinality counts and sample values, sorted highest first. Samples help distinguish unbounded values such as UUIDs from bounded dimensions such as status codes. This tool does not show whether the metric is used; call signoz_check_metric_usage before recommending a drop.

• Parameters:
  • metricName (required) - Metric name to inspect. Example: k8s.container.memory_limit
  • timeRange (optional) - Relative time range <number><unit> where unit is m/h/d (e.g. '30m', '1h', '6h', '24h', '3d', '7d'; default: '7d'; ignored when both start and end are provided)
  • start/end (optional) - Unix ms timestamps. When both are provided, they override timeRange

signoz_list_alerts

Lists currently firing/silenced/inhibited alert instances from Alertmanager, not rule definitions. Use signoz_list_alert_rules for configured rules, signoz_get_alert with an id for one full rule definition, or signoz_get_alert_history for the state timeline.

• Parameters:
  • limit (optional) - Maximum number of alerts per page (default: 50)
  • offset (optional) - Number of results to skip for pagination (default: 0)
  • active / silenced / inhibited (optional) - Tri-state filters. Boolean (or the strings "true"/"false"). Omit to defer to the backend default (all states included). An invalid value is rejected rather than silently dropped
  • filter (optional) - Comma-separated alert-label comparisons using =, !=, =~ (regex), or !~ (negative regex), e.g. alertname="HighCPU",severity="critical"
  • receiver (optional) - Regex to filter alerts by receiver name

signoz_list_alert_rules

Lists configured alert-rule summaries from GET /api/v2/rules, including inactive/OK and disabled rules. Use signoz_get_alert for one full definition; use signoz_list_alerts for current Alertmanager instances.

• Parameters:
  • limit (optional) - Maximum number of rules to return per page (default: 50, max: 1000; higher values are clamped)
  • offset (optional) - Number of rules to skip for pagination (default: 0)

signoz_get_alert

Gets one alert rule's full definition (GET /api/v2/rules/{id}). Use signoz_list_alert_rules to discover IDs. Before signoz_update_alert, call this only when a complete current definition is not already available for the prepared operation; reuse a still-current result and preserve unchanged fields.

• Parameters: id (required) - Alert rule ID (UUIDv7 on v2-capable servers).
• Note: Response shape depends on the SigNoz server version. Post-#10997 servers return the canonical Rule type with createdAt/updatedAt/createdBy/updatedBy; older servers return GettableRule with createAt/updateAt/createBy/updateBy (no 'd').

signoz_list_dashboards

Lists paginated tenant-dashboard summaries (name, UUID, description, tags, timestamps). Use signoz_get_dashboard for panel and query definitions, and page by raising offset by limit until you have covered total before concluding a dashboard is absent.

• Parameters:
  • limit (default 50), offset (default 0) – offset-based pagination
  • filter (optional) – server-side filter DSL over dashboard metadata (name, description, tags, creator, timestamps, locked state)
  • sort (optional) – updated_at (default), created_at, or name
  • order (optional) – asc or desc (default desc)

Only source: user dashboards can be updated, patched, or deleted. source is not a server-side list-filter column; filter returned rows locally across pages when needed.

The filter DSL is a boolean expression of key operator value terms and bare free-text words joined with AND/OR/NOT and parentheses (e.g. name CONTAINS 'overview' AND locked = true). Read signoz://dashboard/list-filter-guide for the full grammar, the filterable keys with their operators, value formats, and worked examples; the list response also echoes the authoritative reserved-key set in reservedKeywords.

signoz_get_dashboard

Gets one known tenant dashboard's complete layout, variables, panels, and queries. Use signoz_list_dashboards to discover the UUID.

• Parameters: id (required) - Dashboard UUID

signoz_create_dashboard

Creates a custom multi-panel dashboard. Use signoz_import_dashboard when a curated template fits, or signoz_create_view to save one Explorer query. Read signoz://dashboard/instructions, signoz://dashboard/widgets-instructions, and signoz://dashboard/widgets-examples before composing the payload.

• Parameters:
  • schemaVersion (required) – Must be "v6"
  • name (DNS-1123 label) or generateName: true to derive it from spec.display.name
  • tags (required) – Array of key/value tags (may be empty)
  • spec (required) – Perses spec: display, variables (array), panels (map keyed by panel id), layouts (array)

Static Markdown panels use signoz/TextPanel with queries: [], plus plugin.spec.mode: "markdown", text, presentation, and headerOptions. Include the panel's layout reference. Query-bearing panels still require one query; Text panels do not need a query dry run. Widget examples and patch instructions include both kinds. Area charts use signoz/AreaChartPanel with one time_series query; visualization.stack (none, normal, or percent) stacks grouped series, and chartAppearance.fillMode is solid or gradient. Dashboard inputs use canonical id; the legacy uuid input is rejected on the changed dashboard tools.

signoz_import_dashboard

Creates a dashboard from a curated template hosted in the SigNoz/dashboards repo (main branch). The server fetches the template JSON and creates the dashboard in one call.

When the relative template path is unknown, call signoz_list_dashboard_templates first. Pass its path, not a URL or absolute path.

• Parameters:
  • path (required) – Template path within the SigNoz/dashboards repo, e.g. hostmetrics/hostmetrics.json

Documentation truncated — see the full README on GitHub.