crowdsec-mcp
# crowdsec-mcp
A read-only MCP server for CrowdSec, exposing decisions and alerts.
## Tools
| name | endpoint | required secret |
| --- | --- | --- |
| `list_decisions` | `GET /v1/decisions` | bouncer key |
| `decisions_stream` | `GET /v1/decisions/stream` | bouncer key |
| `list_alerts` | `GET /v1/alerts` | machine login |
| `get_alert` | `GET /v1/alerts/{id}` | machine login |
## Credentials
We need two credential types:
- **Decisions** need only a **bouncer API key** (`cscli bouncers add <name>`), which is
inherently read-only. This alone is enough for `list_decisions` / `decisions_stream`.
- **Alerts** are only reachable with **machine credentials** (`cscli machines add`),
exchanged for a short-lived JWT. That credential is technically read-write on LAPI, so
this server only ever issues GET requests (plus the login POST). The alert tools stay
disabled unless machine credentials are configured.
## Configuration (environment variables)
| name | default | use |
| --- | --- | --- |
| `CROWDSEC_LAPI_URL` | `http://localhost:8080` | LAPI base URL |
| `CROWDSEC_BOUNCER_KEY` | — | bouncer API key (enables decision tools) |
| `CROWDSEC_MACHINE_ID` | — | machine id (enables alert tools) |
| `CROWDSEC_MACHINE_PASSWORD` | — | machine password |
| `CROWDSEC_VERIFY_TLS` | `true` | set `false` to skip TLS verification |
TDQS
Scored across 4 tools
The four tools target two distinct resources (decisions and alerts) with clear action prefixes (list, get, stream). The main ambiguity is between list_decisions and decisions_stream, both dealing with decisions, but one implies a static list and the other a real-time stream. Overall, the purposes are distinguishable.
Three tools follow the verb_noun pattern (list_decisions, list_alerts, get_alert), but decisions_stream breaks this pattern with a noun_noun structure. The underscores are consistent, but the mix of verb-leading and noun-leading names is a minor inconsistency.
With 4 tools, the set is within the typical well-scoped range (3-15). The count feels minimal but appropriate for a read-only client focused on listing and streaming decisions and alerts. It could be slightly more comprehensive, but it is not excessive.
The domain is CrowdSec decisions and alerts, and the set covers listing and streaming decisions, plus listing and fetching alerts. Notable gaps include a get_decision operation and any mutation endpoints (create/update/delete). These are common expectations in such a domain, so the surface is incomplete but not severely so.