-
-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ
Because tools/list goes to the model on every request, and sending all 531 costs about
100,000 tokens before anyone types anything. The default is an index: 28 tools, ~4,900 tokens.
Nothing becomes unreachable. cyberchef_bake runs any of the 504 by name, and
cyberchef_categories → cyberchef_list_operations → cyberchef_describe_operation walks down to
any of them. Set CYBERCHEF_TOOL_SURFACE=curated (106) or =all (531) if you would rather
pre-load. Full detail: The Tool Surface.
cyberchef_xor_key_length, cyberchef_cyclic_pattern, cyberchef_hash_identify and
cyberchef_rsa_attack, added in v2.4.0. An operation is a pure run(input, args) over one input,
which cannot express an analysis — and cyberchef_bake cannot either, because a recipe is a
pipeline, not a loop. They are in every tool surface because none is reachable through bake. See
Analysis Tools.
It is a fork of it. All 504 operations come from gchq/CyberChef v11.4.0, mirrored verbatim. What this project adds is the MCP server around them: tool schemas, transports, recipe storage, streaming, batching.
Anything under src/core/ is upstream code and is never hand-edited here — deliberate changes are
carried as patches under patches/fork/, which are re-applied after each sync and fail the sync
if they stop applying. That mechanism exists because a security mitigation was once hand-edited
into src/core/ and silently reverted by a later sync, staying gone for four releases while three
documents claimed it was active.
From v2.0.0 onward. Apache-2.0 is one-way compatible into GPLv3, so upstream's code keeps its own licence and headers while the combined work is GPLv3. The v1.9.x line remains Apache-2.0.
The reason is planned work: two reference projects intended for integration are GPL (katana is GPLv3-or-later, which forces v3 specifically). See ADR 0001.
Because MCP's tool namespace is flat per session. Removing the prefix was announced as a breaking
change in v1.8.0 and withdrawn in v2.0.0 after measurement: it saved 1,208 tokens — 2.6% of the
payload — and produced 19 names that would collide with other servers, including search, diff,
filter, sort, merge and fork. The prefix is permanent.
Yes — clone, npm install, npx grunt configTests, npm run mcp. See Installation.
Publishing to npm is prepared as of v2.3.0 — the install script that blocked it is gone, and a
--ignore-scripts install of the packed tarball starts and serves — but the package is not yet
on the registry, so npx cyberchef-mcp does not work today. server.json carries no npm record
for the same reason.
Both 2026-07-28 and the 2025 era, from one set of handlers, on stdio and HTTP. A client using
the older initialize handshake still negotiates 2025-11-25 and is unaffected.
The operations are CyberChef's, with CyberChef's properties — several are parsers over untrusted
bytes. The MCP layer adds input-size limits, an operation timeout, concurrency and rate limits, and
structured errors. The container runs non-root (UID 65532) on a distroless base and supports
--read-only.
The honest caveat, which upstream states too: no guarantee is offered for the correctness or security of cryptographic operations. Treat it as an analysis tool, not a security boundary.
No. Telemetry is off by default, and when enabled it is local-only — cyberchef_telemetry_export
returns it to you. The only outbound network access in the whole operation set is from two
operations that exist to make requests: HTTP request and DNS over HTTPS. Both are marked
openWorldHint: true so a client can prompt before running them.
Paste it into cyberchef_bake. Both argument forms work — positional arrays as the web UI writes
them, and named objects:
{ "input": "…", "recipe": [{ "op": "From Base64" }, { "op": "Gunzip" }] }Because node:vm is not a security boundary, and that was measured rather than argued: a capability
handed into a vm context reaches the real process through its own constructor, and every useful
tool needs at least one capability. Tools are registered by explicit import, in a reviewed pull
request. See Security and
ADR 0002.
Yes, over HTTP — each session gets its own server and transport instance. Sharing them leaks data
between clients, which is the substance of the SDK's own GHSA-345p-7cg4-v4c7 advisory. Bind to
127.0.0.1: there is no authentication on any transport. See Transports.
The site is generated from docs/ and from the
server's own OperationConfig, so it cannot drift from the code. The wiki is the practical layer
and is editable without a pull request. If they disagree, the site is right.
v2.4.0 · upstream CyberChef v11.4.0 · GPL-3.0-or-later
Maintained in docs/wiki/ and published here automatically — edit the repository, not the wiki, or your change is overwritten on the next sync.
Getting started
Using it
Operating it
Help
The project