Nightingale MCP Server

English | 中文

An MCP (Model Context Protocol) server for Nightingale monitoring system. This server enables AI assistants to interact with Nightingale APIs for alert management, monitoring, and observability tasks through natural language.

Compatibility

• Nightingale: v8.0.0+

Key Use Cases

• Alert Management: Query active and historical alerts, view alert rules and subscriptions
• Target Monitoring: Browse and search monitored hosts/targets, analyze target status
• Incident Response: Create and manage alert mutes, notification rules, and event pipelines
• Team Collaboration: Query users, teams, and business groups

Quick Start

1. Get an API Token

1. Make sure HTTP.TokenAuth is enabled in config.toml:

  [HTTP.TokenAuth]
  Enable = true

2. Log in to your Nightingale web interface
3. Navigate to Personal Settings > Profile > Token Management
4. Create a new token with appropriate permissions

Security Note: Store your API token securely. Never commit tokens to version control. Use environment variables or secure secret management.

2. Configure MCP Client

Cursor (stdio mode, default)

Add to your ~/.cursor/mcp.json:

{
  "mcpServers": {
    "nightingale": {
      "command": "npx",
      "args": ["-y", "@n9e/n9e-mcp-server", "stdio"],
      "env": {
        "N9E_TOKEN": "your-api-token",
        "N9E_BASE_URL": "http://your-n9e-server:17000"
      }
    }
  }
}

HTTP mode (optional)

To run the server over HTTP (MCP streamable transport, JSON only, no SSE), start the server with the http subcommand.

Shared vs non-shared (HTTP only):

• --shared=false (default): Token and base URL may be omitted at startup. Each client can provide X-User-Token and X-N9e-Base-Url in mcp.json so everyone uses their own Nightingale identity or instance. If you do set N9E_TOKEN and N9E_BASE_URL at startup, they act as defaults and clients can still override via headers.
• --shared=true: Startup must set N9E_TOKEN and N9E_BASE_URL. The server uses only this config; client headers X-User-Token and X-N9e-Base-Url are ignored. Use this when the MCP server is a shared org service and users must not override credentials.

# Non-shared: users supply token/URL in mcp.json (or you set defaults at startup)
n9e-mcp-server http --listen :8080

# Shared: one token/URL for all; require at startup, ignore client headers
N9E_TOKEN=xxx N9E_BASE_URL=https://n9e.example.com n9e-mcp-server http --listen :8080 --shared

Cursor: connect to HTTP server

If the server is already running in HTTP mode (e.g. on http://localhost:8080), add a URL-based entry to ~/.cursor/mcp.json (no command/args; Cursor will use the streamable HTTP transport).

Token: You can use either source; you do not need to pass token in mcp.json if the server was started with N9E_TOKEN.

1. Server startup only – Set N9E_TOKEN when starting the server (e.g. N9E_TOKEN=xxx ./n9e-mcp-server http). All clients will use this token; no headers needed in Cursor.
2. Client headers (optional) – The client can send:
   • X-User-Token: use this token for N9e API calls instead of the startup token.
   • X-N9e-Base-Url: use this URL as the Nightingale API base (e.g. https://n9e.other-env.com) instead of the server's N9E_BASE_URL. So each user can point to a different Nightingale instance or use their own token (or both).

Example when the server was started with N9E_TOKEN (no header needed in Cur

... View full README on GitHub