Announcing chirpstack-mcp-server — manage and live-debug LoRaWAN devices from an AI coding agent (gRPC)

Hi all,

I have been building an application on top of ChirpStack and wanted my coding agent
(Claude Code, but any MCP client works) to be able to enqueue a downlink, watch the
uplink come back, tweak the payload codec and check link quality without me copying
things between the web UI and the editor. So I wrote an MCP server for it:

• GitHub: https://github.com/oliveres/chirpstack-mcp-server (MIT)
• Install: uvx chirpstack-mcp-server with CHIRPSTACK_SERVER=host:8080 and
  CHIRPSTACK_API_KEY=… — talks to the native gRPC API (same port as the web UI),
  no REST proxy needed.

What it does:

• 81 tools in 10 toolsets (devices, debug, applications, profiles, gateways on by
  default; multicast, fuota, integrations, tenants, relay opt-in) — a thin, faithful
  layer over the gRPC services, nothing vendor-specific.
• The interesting part is debug: capture_start opens the device event/frame
  stream (InternalService.StreamDeviceEvents etc.) in the background into a ring
  buffer, the agent enqueues a downlink and reads what arrived with capture_read
  (decoded uplinks with fPort/fCnt/hex/codec object/RSSI/SNR, ack/txack, log events).
  wait_for_event and device_recent_events cover the quick-look cases.
• profile_set_codec updates only the codec so an agent can iterate a decoder while
  watching uplinks.
• Session keys and stored integration credentials are redacted from tool output unless
  explicitly requested; destructive tools carry the MCP destructiveHint.

Things I learned about the API on the way, in case they are useful to others:

• GetVersion / ListRegions on InternalService reject API keys (user sessions
  only), and TenantService.List rejects tenant-scoped keys — the server uses
  DeviceProfileService.ListAdrAlgorithms as its connectivity/key check because it is
  the one call every key kind can make.
• The stream endpoints accept plain API keys and replay the last ~10 items from Redis
  on connect.

Tested against ChirpStack 4.19.1 (the integration tests spin up chirpstack-docker).

My question to people who know the API better than I do: are there calls you would
expose differently, and does the event/frame normalization match what you would expect
from the MQTT integration payloads? Bug reports and PRs welcome on GitHub.