Overview
What it does
The appliance is meant to fit into your stack, not replace it. Two open interfaces let you read its data and drive its behaviour — a REST API for programmatic control and a native Model Context Protocol (MCP) server for AI clients. Two outbound paths carry its data elsewhere — a Prometheus scrape endpoint for monitoring and Vector forwarding for SIEM and data lakes. A new integration lands as a card on a single Integrations panel, so there is one place to discover what the appliance can plug into.
Everything here is documented and browsable, so an engineer can wire it up without guessing. The honest framing matters: the AI interface reads by default and writes only behind an admin token, the metrics endpoint is platform-health only, and every outbound path is something you opt into.
REST API
A documented REST surface
The appliance exposes a large REST API — 200+ endpoints covering device lookup, traffic queries, firewall state, enforcement actions, automation rules, reports, and configuration. Anything the GUI shows, the API can return, so you can script reporting, fold the appliance into a runbook, or build your own dashboards on top of it. Requests authenticate with a JWT; a WebSocket stream is available for live transaction data.
The appliance becomes a component you can automate — driven from your own tooling, not a box you only click through.
MCP
Native MCP server for AI clients
A native MCP server lets Claude Code, Claude Desktop, or any MCP client query your DHCP traffic, triage alarms, and apply enforcement — in plain language, against live data from your own appliance. It ships in the appliance package; there is nothing to install or build.
The server exposes 45 tools: 41 read-only tools spanning device lookup, firewall state, system health, time-series metrics, and automation, plus 4 write tools that apply enforcement. The bundled credential is read-only, so an assistant can investigate freely without changing anything. The four write tools unlock only when an administrator supplies an elevated token, and each records a reason in the audit trail. The transport is ordinary SSH: there is no MCP port to open or scan, and every tool call is audit-logged on the appliance.
- 1
Your MCP client opens an SSH session to the appliance using a public key.
- 2
SSH spawns the bundled MCP server as a short-lived subprocess and pipes its input and output back over the encrypted channel.
- 3
That subprocess authenticates to the local API over the appliance's loopback interface only — the token never crosses the network.
- 4
Read tools answer with the bundled read-only credential. Write tools require an administrator to inject an elevated token for that session.
To take enforcement off the table entirely — even when an admin token is present — the server can be started in a hard read-only mode that removes the four write tools so they cannot even be discovered. In that mode the catalogue is the 41 read tools only.
API documentation
An open, browsable reference
The full API is documented as an open reference you can browse — every endpoint, its parameters, and its response shape, alongside authentication and WebSocket details and worked examples. The benefit is short time-to-first-call: an engineer can read the reference and integrate without reverse-engineering the GUI.
Prometheus
Metrics for your monitoring stack
A bearer-token-authenticated scrape endpoint exports metrics in the standard Prometheus exposition format, so you can pull appliance health into the monitoring stack and Grafana dashboards you already run. The scope is deliberate and enforced: it exposes platform health only — build and uptime, alarm-engine state, the notification dispatcher, ClickHouse connectivity, and Go-runtime gauges — and never any client MAC, DUID, IP, or per-device counter. Tokens are admin-issued, labelled, and revocable, and the endpoint is mounted only when you enable it in configuration. The benefit is one consistent place to answer "is the appliance healthy?" without opening a side channel onto subscriber traffic.
scrape_configs:
- job_name: dhcp-shield
metrics_path: /api/metrics/prometheus
scheme: https
scrape_interval: 30s
authorization:
type: Bearer
credentials: <scrape-token>
static_configs:
- targets:
- appliance.example.comVector
Forward events through Vector
The appliance can forward events and records through a Vector sink to downstream systems — a SIEM, a data lake, or any pipeline Vector can reach. This is the outbound path for traffic-level and event data, kept separate from the platform-health metrics that Prometheus scrapes. The Prometheus surface even reports whether the Vector sink's circuit breaker is open, so you can monitor the forwarding path itself. The benefit is that the appliance's data lands where your analysts already work, without manual export.
Keep reading