CyberChef MCP Server

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: v3.8.0 | Release Notes | Tutorial | Examples | Breaking Changes | Security Policy

Upstream base: GCHQ CyberChef v11.4.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.
• Starts in ~185 ms (v2.6.0): it used to take ~1.3 seconds, of which ~1.15 s was importing all 504 operation implementations before answering anything — paid on every launch, on stdio, which is how every editor starts the server. The 504-operation barrel is now loaded only by the three tools that need it (cyberchef_search, batch search, and saved-recipe execution). tools/list is built from metadata, and an ordinary operation call loads just the one operation it runs — verified: cyberchef_bake completes without the barrel being loaded at all. A background warm-up was tried, measured, and removed: module loading blocks the event loop, so it just moved the cost in front of the first request.
• Deployable as a service (v2.6.0): a Helm chart and Compose file with liveness/readiness/startup probes and a drain that loses no requests during a rolling update. Liveness deliberately stays healthy while draining — a liveness failure there gets the pod killed mid-drain. The chart refuses to render configurations the server would reject at startup, so they fail at helm template rather than as a crashloop.
• Bounded calls to the authorization server (v2.6.0): JWKS discovery had no timeout (Node's fetch has none by default) and cached failures not at all, so an issuer outage turned every request into two outbound ones that could hang until the OS gave up. Now a 5 s deadline and a circuit breaker: 20 verifications against a down issuer went from 40 outbound attempts to 10.
• Eighteen analysis tools that are not operations (v2.4.0, expanded through v3.8.0): the original four are cyberchef_xor_key_length (repeating-key XOR length by index of coincidence), cyberchef_cyclic_pattern (De Bruijn patterns and overflow offsets, byte-compatible with pwntools' cyclic), cyberchef_hash_identify (hash format with the hashcat mode and John format name) and cyberchef_rsa_attack (Fermat, shared factors, Wiener and unpadded small-e). Twelve more arrived in v3.3.0 (classical ciphers, crib dragging, entropy scanning, hash cracking and statistics, JWT weaknesses, plaintext scoring, multi-key RSA, substitution and Vigenère breaking, timestamp identification, corpus diffing), then cyberchef_ecdsa_recover in v3.4.0 (private-key recovery from a reused ECDSA nonce) and cyberchef_cert_chain in v3.8.0 (orders an X.509 bundle, verifies every link cryptographically, and reports the chain's validity window as the intersection of its members', both ends). See Analysis Tools. An operation is a pure run(input, args) over one input and cannot express an analysis; cyberchef_bake cannot either, because a recipe is a pipeline, not a loop. Exposed at every tool surface. There is deliberately no plugin loader — node:vm is not a security boundary, and that was measured rather than assumed (ADR 0002).
• Protocol revision 2026-07-28 (v2.3.0): served on both stdio and HTTP alongside the 2025 era, from one set of handlers. Existing clients are unaffected — a v1-SDK client still negotiates 2025-11-25 against the same registrations. On HTTP the two eras are routed per request by the SDK's own classifier, so 2025 traffic keeps the sessionful wiring while modern traffic is served per request.
• Three transports (v2.3.0): stdio, Streamable HTTP, and a socket binding over a Unix domain socket or loopback TCP (CYBERCHEF_TRANSPORT=socket), one pinned server instance per connection. It carries no authentication, so a non-loopback bind is refused unless explicitly allowed and the Unix socket is created 0600. There is deliberately no WebSocket transport — MCP does not define one.