doublegate/CyberChef-MCP

This project provides a **Model Context Protocol (MCP)** server interface for **CyberChef**, the "Cyber Swiss Army Knife" created by GCHQ.
By running this server, you enable AI assistants (like Claude, Cursor AI, and others) to natively utilize CyberChef's extensive library of **504 data manipulation operations**—including encryption, encoding, compression, and forensic analysis—as executable tools.
**Latest Release:** v4.2.0 | Release Notes | Tutorial | Examples | Breaking Changes | Security Policy
**Upstream base:** GCHQ CyberChef **v11.5.0** | **Licence:** GPL-3.0-or-later (from v2.0.0; v1.9.x and earlier remain Apache-2.0)
Project Context
**CyberChef** is a simple, intuitive web app for carrying out all manner of "cyber" operations within a web browser. It was originally conceived and built by GCHQ.
This fork wraps the core CyberChef Node.js API into an MCP server, bridging the gap between natural language AI intent and deterministic data processing.
Fork Relationship
This project maintains a selective sync relationship with the upstream GCHQ/CyberChef repository:
- **Synced from upstream**: src/core/** (minus three generated paths) and six upstream-owned
files in src/node/. Mirrored verbatim — **never hand-edit them**; fork changes live as
re-applied patches.
- **Web UI Components**: Removed (88 files, ~19,260 lines) — not needed for an MCP server
- **MCP-Specific Code**: this fork's own (src/node/mcp-server.mjs, src/node/lib/**, tests/mcp/,
workflows)
- **Sync is one-way**: pull only. As of v2.0.0 the combined work is GPL-3.0-or-later, so MCP-layer
changes cannot be contributed back to an Apache-2.0 upstream.
Exact scope, the patch model, and what to do when a sync conflicts:
**Upstream Sync Guide**.
See Upstream Sync Guide for details on the synchronization process.
Features
MCP Tools
The server exposes CyberChef operations as MCP tools:
* **Runs on ARM, and 30% smaller** (v2.8.0): images are published for linux/arm64 as well as linux/amd64 — Apple Silicon, Graviton, Raspberry Pi 4/5 — and the image is down from 643 MB to **453 MB**. Also **CYBERCHEF_OFFLINE=true** for air-gapped hosts: 502 of the 504 operations never touched a network anyway, so this is a fail-closed switch for the two that do, checked against the *recipe* rather than the tool name. See the edge deployment guide for architectures, sizing and air-gapped install, and the release notes for how the size reduction was done and verified.
* **Observable** (v2.7.0): a dependency-free Prometheus endpoint at /metrics (20 metric families, **off by default** — unlike the health probes it reports which tools are used, how often and how large the inputs are, which is a reconnaissance surface), OpenTelemetry spans following the MCP semantic conventions, and trace_id/span_id on every log line. It adds **one** package: the OTel *API*, not the SDK — measured at 1 package / 2.6 MB / +9 ms against the SDK's 71 packages / 50 MB / +100 ms, which would have handed back more than half of v2.6.0's startup work on every stdio launch. You supply the SDK, so every OTLP backend works rather than a chosen few. Ships a Grafana dashboard, alert rules and a runnable Prometheus stack — all executed against a live server rather than reviewed. Tool arguments are **never** recorded: the conventions mark them Opt-In, and for this server the arguments *are* the sensitive material.
* **OAuth 2.1 authentication on HTTP** (v2.5.0): the server acts as an OAuth 2.1 **Resource Server** — RFC 9728 Protected Resource Metadata, JWKS-based bearer validation, and RFC 8707 audience binding, which is the check that stops a token minted for another service being replayed here. Scope-based RBAC with three scopes (cyberchef:read, cyberchef:write, cyberchef:network), where the scope a tool needs is *derived from its annotations* rather than a table that goes stale. Audit logging for who called what. **Off unless CYBERCHEF_AUTH_ISSUER is set**, and deliberately not applied to stdio — the MCP specification says stdio SHOULD NOT use OAuth, because a bearer token protects nothing when the client already owns the process.
* **Multi-tenancy** (v2.5.0): the operation cache, recipe store, concurrency pool and audit trail are isolated per tenant, with the tenant read from a claim on an already-verified token (CYBERCHEF_TENANT_CLAIM) — never from a header the caller controls. Without it, any caller on a shared HTTP deployment could list, modify and delete any other caller's saved recipes, and clear() destroyed every tenant's at once. **Off unless configured**, and configuring it without CYBERCHEF_AUTH_ISSUER is a startup error rather than a silent downgrade.