# ChirpStack [Health: Active]

**Category:** 🏭 Industrial & IoT  
**Repository:** https://github.com/oliveres/chirpstack-mcp-server  
**GitHub Stars:** 0  
**Views:** 3  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/chirpstack

## Description
Manage and live-debug LoRaWAN devices on a ChirpStack v4 network server over its gRPC API

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `uvx` (confidence: high):

```json
"mcpServers": {
  "chirpstack": {
    "command": "uvx",
    "args": ["chirpstack-mcp-server"],
    "env": {
      "CHIRPSTACK_SERVER": "",
      "CHIRPSTACK_API_KEY": "",
      "CHIRPSTACK_TOOLSETS": "",
      "CHIRPSTACK_TLS": "",
      "CHIRPSTACK_TRANSPORT": "",
      "CHIRPSTACK_HTTP_PORT": ""
    }
  }
}
```

**Requires environment variables:** `CHIRPSTACK_SERVER`, `CHIRPSTACK_API_KEY`, `CHIRPSTACK_TOOLSETS`, `CHIRPSTACK_TLS`, `CHIRPSTACK_TRANSPORT`, `CHIRPSTACK_HTTP_PORT` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What the ChirpStack MCP server does

The ChirpStack MCP server exposes ChirpStack v4 operations through the Model Context Protocol. It is intended for LoRaWAN network administration and for live debugging during device application development. The server does not add device- or vendor-specific logic; it forwards supported operations to ChirpStack's native gRPC API.

The default toolsets cover devices, debugging, applications, device profiles, and gateways. Optional toolsets add multicast groups, FUOTA deployments, integrations, tenants, and relay resources. Tool visibility can be limited so an agent receives only the operations relevant to a task.

## How it works

The ChirpStack MCP server authenticates to the ChirpStack API with an API key read from the environment. Its default transport is stdio, and it can also serve MCP over streamable HTTP on a loopback port. TLS can be enabled for the connection to ChirpStack.

For live diagnostics, an agent can start a capture for a device or gateway. Device captures use a background stream and a ring buffer, allowing the agent to read new events between tool calls. Captured data can include decoded uplinks, frame counters, payload bytes, codec output, per-gateway RSSI and SNR, downlink acknowledgements, and log entries. A shorter workflow can wait for the next event or retrieve recent device history.

Class A devices receive queued downlinks after their next uplink, while Class C devices can receive them immediately. Capture sessions expire after 30 minutes when idle.

## Setup and configuration

Install the package with `uvx chirpstack-mcp-server` or install it with pip. Set these required variables:

- `CHIRPSTACK_SERVER`: the ChirpStack API host and port, commonly the web UI port such as `8080`.
- `CHIRPSTACK_API_KEY`: a tenant or global administrator API key created in ChirpStack.

Optional settings select toolsets, enable TLS, choose `stdio` or `streamable-http`, and set the HTTP port. The default toolsets are `devices, debug, applications, profiles, gateways`; use `all` or a comma-separated list to enable additional groups.

Claude Code can register the server with its MCP command-line configuration. Claude Desktop and other MCP clients can use a standard server entry with the executable and environment variables.

## Tools and capabilities

The ChirpStack MCP server includes tools for:

- Listing, reading, creating, updating, and deleting devices, applications, profiles, and gateways.
- Setting device keys, activating or deactivating devices, flushing nonces, queuing downlinks, and viewing device metrics.
- Starting, reading, listing, and stopping captures, waiting for events, and inspecting recent device events.
- Updating a profile's codec and listing profile vendors or ADR algorithms.
- Managing multicast groups, FUOTA deployments, integrations, tenants, tenant users, API keys, relay devices, and relay gateways when those toolsets are enabled.

The `server_info` tool is intended as an initial connection and credential check. ChirpStack may return empty version or region fields for API-key requests because those values are served only to logged-in user sessions.

## Limitations and notes

Plain HTTP/2 is the default and sends the API key as a cleartext bearer token, so it should be limited to a trusted LAN. Use TLS behind a suitable gRPC-speaking proxy or use a VPN for other network locations. The streamable HTTP listener has no separate authentication and binds to `127.0.0.1`; it should not be exposed publicly.

Sensitive values receive special handling. API keys do not appear in tool output, device and session keys are hidden unless explicitly requested, and integration credentials are redacted by default. Tenant administration can create API keys, and the newly created token is returned once. Destructive operations are annotated so compatible MCP clients can request confirmation.

_Full upstream README: https://allmcps.com/mcp/chirpstack/readme_