This server exposes GCHQ CyberChef's 504 data-manipulation operations plus 19 crypto-analysis tools to AI assistants over MCP, with recipe management and batch execution on top.
Run recipes — cyberchef_bake executes a chain of operations (e.g. Base64 decode → Gunzip → JSON beautify) on an input, with named or positional arguments.
Magic auto-detect — cyberchef_magic guesses what the data is and suggests/unwraps encodings, with optional intensive XOR/brute-force mode and known-plaintext crib filtering.
Discover operations — cyberchef_categories → cyberchef_list_operations → cyberchef_describe_operation walks down to any of the 504 operations, or cyberchef_search finds one by keyword.
Analysis tools — cyberchef_analyse runs 19 non-operation analyses: XOR key length, hash identification, cyclic patterns, RSA/ECDSA attacks, classical cipher breaking, crib dragging, entropy scanning, plaintext scoring, timestamp ID, X.509 chain validation, post-quantum (ML-KEM/ML-DSA/SLH-DSA) identification.
Recipe management — create, get, list, update, delete, execute, export/import (JSON/YAML/URL/CyberChef), validate and test saved multi-operation workflows, referenced as recipe://<id> resources.
Batch processing — cyberchef_batch runs many operations in parallel or sequentially with partial success.
Server administration — cyberchef_cache_stats/cyberchef_cache_clear, cyberchef_quota_info, cyberchef_worker_stats, and cyberchef_telemetry_export for cache, resource quota, worker pool and usage introspection.
Five workflow prompts — analyse-unknown-data, extract-iocs, deobfuscate-script, identify-hash, decode-chain for when you don't yet know which operation to use.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CyberChef MCP Server decode this base64 string"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.4.0 | Licence: GPL-3.0-or-later (from v2.0.0; v1.9.x and earlier remain Apache-2.0)
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.
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.
Related MCP server: Ghidra MCP Server
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.
Nineteen analysis tools that are not operations (v2.4.0, expanded through v3.11.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). cyberchef_pqc_identify arrived in v3.11.0: it names the NIST post-quantum parameter set behind a key, signature or ciphertext — ML-KEM (FIPS 203), ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) — from the OID when there is DER to read, and from byte length when there is not, in which case it reports every candidate and says so rather than picking one. 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. Since v4.1.0 they are reached through cyberchef_analyse({tool, arguments}) on the default index surface, and remain listed outright on curated and all — nineteen of them had been 68% of the index, listed only because cyberchef_describe_operation refused them and pointed at tools/list, which made the listing their sole schema path. 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.
Every image operation works (v2.3.0): 17 of them returned Node's shared buffer pool instead of the image — unreadable output, and the surplus was whatever the process had recently allocated. Add Text To Image had never worked in this fork at all, since v1.7.1. Both are fixed as fork patches.
Images and audio come back as images and audio (v2.2.0): Generate QR Code, Render Image and the image set return an MCP image content block; Play Media returns an audio block. Before v2.2.0 the html-to-text conversion deleted the payload and these operations returned an empty string — they had never worked over MCP. Other binary stays byte-lossless latin1 text, or base64 with CYBERCHEF_BINARY_OUTPUT=base64.
Tool annotations on every tool (v2.2.0): readOnlyHint, destructiveHint, idempotentHint, openWorldHint and a readable title, so a client can skip the approval prompt for a pure operation. The exceptions were measured, not guessed — only HTTP request and DNS over HTTPS reach the network, and non-idempotence was determined by running each candidate twice and comparing.
Prompts and resources (v2.2.0): five workflow prompts (analyse-unknown-data, extract-iocs, deobfuscate-script, identify-hash, decode-chain) for when you do not yet know which of 504 operations you need, and saved recipes exposed as readable resources at recipe://<id>.
cyberchef_bake: The "Omni-tool". Executes a full CyberChef recipe (a chain of operations) on an input. Ideal for complex, multi-step transformations (e.g., "Decode Base64, then Gunzip, then prettify JSON").
All 504 operations, without paying for 504 schemas (v2.1.0): tools/list is an index by default — 23 tools and 15,620 bytes, rather than 545 tools and 426,706 bytes. Every operation stays reachable: cyberchef_categories -> cyberchef_list_operations -> cyberchef_describe_operation walks down to any of them, cyberchef_search finds one by keyword, and cyberchef_bake runs any of them by name. The 19 analysis tools are reachable the same way, through cyberchef_describe_operation and cyberchef_analyse — they were listed on every surface until v4.1.0, where nineteen of them were 68% of the index, because describe_operation used to refuse them and point at tools/list, making the listing their only schema path. CYBERCHEF_TOOL_SURFACE=curated (120 tools, 109,548 bytes) or =all (all 545, 426,706 bytes) if you would rather pre-load; both still list every analysis tool outright. See the User Guide.
cyberchef_to_base64 / cyberchef_from_base64
cyberchef_aes_decrypt
cyberchef_sha2
cyberchef_yara_rules
...and hundreds more.
cyberchef_search: A utility tool to help the AI discover available operations and their descriptions.
Recipe Management (v1.6.0): 10 tools for saving, organizing, and reusing multi-operation workflows
cyberchef_recipe_create / cyberchef_recipe_get / cyberchef_recipe_list
cyberchef_recipe_update / cyberchef_recipe_delete / cyberchef_recipe_execute
cyberchef_recipe_export / cyberchef_recipe_import
cyberchef_recipe_validate / cyberchef_recipe_test
Advanced Features (v1.7.0): 5 new tools for enterprise-grade capabilities
cyberchef_batch - Execute multiple operations in parallel or sequential mode
cyberchef_telemetry_export - Privacy-first usage analytics (opt-in)
cyberchef_cache_stats / cyberchef_cache_clear - Cache inspection and management
cyberchef_quota_info - Resource quota and usage tracking
Migration tooling — REMOVED in v4.0.0. cyberchef_migration_preview,
cyberchef_deprecation_stats and the cyberchef-migrate binary existed to help callers reach
v2.0.0, nine minors earlier. They were advertised on every surface and cost 995 bytes of
every tools/list, while the only warning still emitted was DEP007 — a withdrawn code
whose own text read "No action required". Your v1-format recipes need no migration: positional
arguments, bare string operations and named-object arguments all bake identically today.
The cyberchef_ prefix is permanent. DEP001, DEP007 and DEP008 announced its removal in v1.8.0 and were withdrawn in v2.0.0: removing it saves 2.6% of the tools/list payload while colliding 19 tool names in MCP's flat namespace and breaking every existing integration. Keep using cyberchef_to_base64, cyberchef_bake and cyberchef_search. See v2.0.0 Breaking Changes.
Worker Thread Pool (v1.9.0): CPU-intensive operations offloaded to worker threads
cyberchef_worker_stats - Monitor worker pool utilization, active/completed tasks, and pool configuration
Enable with CYBERCHEF_ENABLE_WORKERS=true environment variable
Configurable pool size, idle timeout, and minimum input size for worker routing
Dockerized: Runs as a self-contained Docker container on a Chainguard Wolfi Node.js base (v26.8.1 at time of writing), pinned by digest and bumped weekly by Dependabot. Measured against the published v3.1.0 image: 453 MB on disk, 141 MB as the gzipped release tarball, running as UID 65532 (nonroot). The base is rebuilt daily and carries no package manager (apk, wget and curl are all absent) -- but it does include a BusyBox shell and npm, so treat a container compromise as having a shell available. This line previously claimed "no shell" and "726 MB on disk"; both were wrong, and the correction is recorded in the v3.1.0 baseline.
Dual-Registry Publishing: Images published to both Docker Hub and GitHub Container Registry (GHCR) for maximum accessibility and Docker Scout health score optimization.
Supply Chain Attestations: SBOM and provenance attestations attached to Docker Hub images for enhanced security transparency and compliance (SLSA Build Level 3).
Dual Transport (v1.9.0; per-session HTTP since v2.0.0): Stdio (default) or Streamable HTTP via CYBERCHEF_TRANSPORT=http. Every HTTP client gets its own session and its own MCP server instance, with CORS, DNS-rebinding protection and a session cap. See the HTTP Transport Guide.
MCP Streaming with Progress (v1.9.0): Operations send notifications/progress via the MCP SDK progress token mechanism for real-time status updates during long-running tasks.
Worker Thread Pool (v1.9.0): Piscina-based worker threads offload CPU-intensive operations (AES, Blowfish, bcrypt, scrypt, PBKDF2, etc.) to prevent event loop blocking. Configurable pool size and routing thresholds.
Schema Validation: All inputs are validated against schemas derived from CyberChef's internal type system using zod.
Modern Node.js: Requires Node.js >=26 <27 since v4.0.0, and the published image runs Node 26 -- floor and runtime are now the same version rather than two majors apart.
Recipe Management (v1.6.0): Save and reuse multi-operation workflows with full CRUD operations, import/export in multiple formats (JSON/YAML/URL/CyberChef), recipe composition with nesting support, and curated library of 25+ production-ready recipes across 5 categories. See Recipe Management Guide for details.
Advanced Features (v1.7.0): Enterprise-grade capabilities with batch processing (parallel/sequential execution of up to 100 operations), privacy-first telemetry collection (disabled by default, no input/output data captured), sliding window rate limiting for resource protection, enhanced caching with inspection tools, and resource quota tracking (concurrent operations, data sizes). All features are configurable via environment variables with secure defaults. See Release Notes for details.
Enhanced Observability (v1.5.0): Structured JSON logging with Pino for production monitoring, comprehensive error handling with actionable recovery suggestions, automatic retry logic with exponential backoff, request correlation with UUID tracking, circuit breaker pattern for cascading failure prevention, and streaming infrastructure for progressive results on large operations. See Release Notes for details.
Performance Optimized (v1.4.0): LRU cache for operation results (100MB default), automatic streaming for large inputs (10MB+ threshold), configurable resource limits (100MB max input, 30s timeout), memory monitoring, and comprehensive benchmark suite. See Performance Tuning Guide for configuration options.
Upstream Sync Automation (v1.3.0; rebuilt in v2.0.0): Weekly monitoring of upstream releases, an atomic whole-tree mirror, fork changes carried as patches that fail the sync if they stop applying, comprehensive validation (1,246 MCP + 241 Node-API + 2,289 operation tests), and an emergency rollback. See the Upstream Sync Guide.
Security Hardened (v1.4.5+): Chainguard Wolfi base image with zero-CVE baseline, non-root execution (UID 65532), automated Trivy vulnerability scanning with build-fail thresholds, dual SBOM strategy (Docker Scout attestations + CycloneDX), read-only filesystem support, SLSA Build Level 3 provenance, and 7-day SLA for critical CVE patches. Fixed 11 of 12 code scanning vulnerabilities including critical cryptographic randomness weakness and 7 ReDoS vulnerabilities. See Security Policy and Security Fixes Report for details.
Production Ready: Comprehensive CI/CD with CodeQL v4, automated testing, and dual-registry container publishing (Docker Hub + GHCR) with complete supply chain attestations.
Node.js >=26 <27 for the npm install, or Docker for the container.
Option 1: npm (Recommended)
npx cyberchef-mcpNo clone, no build, no Docker daemon. For an MCP client, point it at the same command:
{
"mcpServers": {
"cyberchef": { "command": "npx", "args": ["-y", "cyberchef-mcp"] }
}
}Installing it permanently works too — npm install -g cyberchef-mcp, then run cyberchef-mcp.
That is the only binary the package ships; cyberchef-migrate was removed in v4.0.0.
Option 2: Pull from Docker Hub
# Docker Hub provides health scores and supply chain attestations
docker pull parobek/cyberchef-mcp:latest
docker tag parobek/cyberchef-mcp:latest cyberchef-mcp
docker run -i --rm cyberchef-mcpOption 2b: Pull from GitHub Container Registry (Alternative)
docker pull ghcr.io/doublegate/cyberchef-mcp_v4:latest
docker tag ghcr.io/doublegate/cyberchef-mcp_v4:latest cyberchef-mcp
docker run -i --rm cyberchef-mcpOption 3: Download Pre-built Image (Offline Installation)
For environments without direct GHCR access, download the pre-built Docker image tarball from the latest release:
Download the tarball (141 MB compressed; measured against the published v3.1.0 asset, not estimated):
# Download from GitHub Releases
wget https://github.com/doublegate/CyberChef-MCP/releases/download/v4.2.0/cyberchef-mcp-v4.2.0-docker-image.tar.gzLoad the image into Docker:
docker load < cyberchef-mcp-v4.2.0-docker-image.tar.gzTag for easier usage:
docker tag parobek/cyberchef-mcp:latest cyberchef-mcpRun the server:
docker run -i --rm cyberchef-mcpOption 4: Build from Source
Clone the Repository:
git clone https://github.com/doublegate/CyberChef-MCP.git
cd CyberChef-MCPBuild the Docker Image:
docker build -f Dockerfile.mcp -t cyberchef-mcp .Run the Server (Interactive Mode): This command starts the server and listens on stdin. This is what your MCP client will run.
docker run -i --rm cyberchef-mcpOptional: Run with Enhanced Security (Read-Only Filesystem): For maximum security in production deployments:
docker run -i --rm --read-only --tmpfs /tmp:rw,noexec,nosuid,size=100m cyberchef-mcpGo to Settings > Features > MCP.
Add a new server:
Name: CyberChef
Type: command
Command: docker
Args: run -i --rm cyberchef-mcp
Add to your configuration file (typically ~/.config/claude/config.json):
{
"mcpServers": {
"cyberchef": {
"command": "docker",
"args": ["run", "-i", "--rm", "cyberchef-mcp"]
}
}
}Add to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"cyberchef": {
"command": "docker",
"args": ["run", "-i", "--rm", "cyberchef-mcp"]
}
}
}After adding the configuration, restart Claude Desktop. The CyberChef tools will appear in the available tools panel.
Version 1.4.0 introduces comprehensive performance optimizations and configurable resource limits. All features can be tuned via environment variables for your deployment needs.
LRU Cache for Operation Results
Automatically caches operation results to eliminate redundant computation
Configurable cache size (100MB default) and item count (1000 default)
Cache keys based on operation + input + arguments (SHA256 hash)
Automatic Streaming for Large Inputs
Inputs exceeding 10MB automatically use chunked processing
Supports encoding, compression, and hashing operations
Memory-efficient handling of 100MB+ files
Transparent fallback for non-streaming operations
Resource Limits
Maximum input size validation (100MB default)
Operation timeout enforcement (30 seconds default)
Prevents out-of-memory crashes and runaway operations
Memory Monitoring
Periodic memory usage logging to stderr
Heap and RSS tracking for troubleshooting
Every setting can be given either in a cyberchef.config.json file or as an environment variable,
with environment variables taking precedence over the file. Nothing is required: with no file,
the server behaves exactly as it always has.
{
"server": { "maxInputSize": 10485760, "operationTimeout": 30000 },
"security": { "offline": true },
"tools": { "surface": "curated" }
}A malformed file, an unknown section or an unknown setting stops the server with a message naming the mistake, rather than starting on defaults nobody chose. All 61 settings, their sections and their environment-variable equivalents are in the configuration guide.
The same settings as environment variables:
# Logging (v1.5.0+)
LOG_LEVEL=info # Logging level: debug, info, warn, error, fatal
# Retry Logic (v1.5.0+)
CYBERCHEF_MAX_RETRIES=3 # Maximum retry attempts for transient failures
CYBERCHEF_INITIAL_BACKOFF=1000 # Initial backoff delay in milliseconds
CYBERCHEF_MAX_BACKOFF=10000 # Maximum backoff delay in milliseconds
CYBERCHEF_BACKOFF_MULTIPLIER=2 # Backoff multiplier for exponential backoff
# Streaming (v1.5.0+)
CYBERCHEF_STREAM_CHUNK_SIZE=1048576 # Chunk size for streaming (1MB)
CYBERCHEF_STREAM_PROGRESS_INTERVAL=10485760 # Progress reporting interval (10MB)
# Recipe Management (v1.6.0+)
CYBERCHEF_RECIPE_STORAGE=./recipes.json # Storage file path
CYBERCHEF_RECIPE_MAX_COUNT=10000 # Maximum number of recipes
CYBERCHEF_RECIPE_MAX_OPERATIONS=100 # Max operations per recipe
CYBERCHEF_RECIPE_MAX_DEPTH=5 # Max nesting depth
# Batch Processing (v1.7.0+)
CYBERCHEF_BATCH_MAX_SIZE=100 # Maximum operations per batch
CYBERCHEF_BATCH_ENABLED=true # Enable/disable batch processing
# Telemetry & Analytics (v1.7.0+)
CYBERCHEF_TELEMETRY_ENABLED=false # Privacy-first: disabled by default
# Rate Limiting (v1.7.0+)
CYBERCHEF_RATE_LIMIT_ENABLED=false # Disabled by default
CYBERCHEF_RATE_LIMIT_REQUESTS=100 # Max requests per window
CYBERCHEF_RATE_LIMIT_WINDOW=60000 # Time window in milliseconds
# Cache Management (v1.7.0+)
CYBERCHEF_CACHE_ENABLED=true # Enable/disable caching
# Resource Quotas (v1.7.0+)
CYBERCHEF_MAX_CONCURRENT_OPS=10 # Maximum concurrent operations
# (Removed in v4.0.0) V2_COMPATIBILITY_MODE and CYBERCHEF_SUPPRESS_DEPRECATIONS went with the
# deprecation system they configured. Do not set them: the `compatibility` section is now an
# unknown section, and `cyberchef.config.json` fails CLOSED on one -- the server refuses to start
# with "unknown section \"compatibility\"". The env vars are simply ignored.
# Transport (v1.9.0+; per-session HTTP since v2.0.0)
CYBERCHEF_TRANSPORT=stdio # Transport type: stdio or http
CYBERCHEF_HTTP_PORT=3000 # HTTP transport port
CYBERCHEF_HTTP_HOST=127.0.0.1 # HTTP bind address (use 0.0.0.0 in a container)
CYBERCHEF_ALLOWED_HOSTS= # Comma-separated Host allowlist. DNS-rebinding protection
# is ON by default (loopback names). Set this when binding
# a non-loopback address; `*` disables the check.
CYBERCHEF_ALLOWED_ORIGINS= # Comma-separated Origin allowlist; enables CORS. Required
# by browser MCP clients (e.g. MCP Inspector's web UI).
CYBERCHEF_SESSION_TIMEOUT=1800000 # Idle HTTP session reap threshold (30 min)
CYBERCHEF_HTTP_MAX_BODY=4194304 # Maximum accepted HTTP request body (4 MiB)
CYBERCHEF_HTTP_PATH=/mcp # MCP endpoint path; any other path returns 404
CYBERCHEF_MAX_SESSIONS=100 # Cap on concurrent HTTP sessions; initialize 503s beyond it
# Worker Thread Pool (v1.9.0+)
CYBERCHEF_WORKER_MIN_THREADS=1 # Minimum worker threads
CYBERCHEF_WORKER_MAX_THREADS=4 # Maximum worker threads
CYBERCHEF_WORKER_IDLE_TIMEOUT=30000 # Worker idle timeout in milliseconds
CYBERCHEF_WORKER_MIN_INPUT_SIZE=1024 # Minimum input size for worker routing (bytes)
# Performance (v1.4.0+)
CYBERCHEF_MAX_INPUT_SIZE=104857600 # Maximum input size (100MB)
CYBERCHEF_OPERATION_TIMEOUT=30000 # Operation timeout in milliseconds (30s)
CYBERCHEF_STREAMING_THRESHOLD=10485760 # Streaming threshold (10MB)
CYBERCHEF_ENABLE_STREAMING=true # Enable streaming for large operations
CYBERCHEF_ENABLE_WORKERS=false # Enable worker thread pool (disabled by default)
CYBERCHEF_CACHE_MAX_SIZE=104857600 # Cache maximum size (100MB)
CYBERCHEF_CACHE_MAX_ITEMS=1000 # Cache maximum itemsHigh-Throughput Server (Large Files)
docker run -i --rm --memory=4g \
-e CYBERCHEF_MAX_INPUT_SIZE=524288000 \
-e CYBERCHEF_STREAMING_THRESHOLD=52428800 \
-e CYBERCHEF_CACHE_MAX_SIZE=524288000 \
-e CYBERCHEF_OPERATION_TIMEOUT=120000 \
ghcr.io/doublegate/cyberchef-mcp_v4:latestLow-Memory Environment
docker run -i --rm --memory=512m \
-e CYBERCHEF_MAX_INPUT_SIZE=10485760 \
-e CYBERCHEF_STREAMING_THRESHOLD=5242880 \
-e CYBERCHEF_CACHE_MAX_SIZE=10485760 \
-e CYBERCHEF_CACHE_MAX_ITEMS=100 \
ghcr.io/doublegate/cyberchef-mcp_v4:latestClaude Desktop with Custom Limits
{
"mcpServers": {
"cyberchef": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "CYBERCHEF_MAX_INPUT_SIZE=209715200",
"-e", "CYBERCHEF_CACHE_MAX_SIZE=209715200",
"ghcr.io/doublegate/cyberchef-mcp_v4:latest"
]
}
}
}Debug Logging for Troubleshooting (v1.5.0+)
docker run -i --rm \
-e LOG_LEVEL=debug \
-e CYBERCHEF_MAX_RETRIES=5 \
ghcr.io/doublegate/cyberchef-mcp_v4:latestWorker Thread Pool for CPU-Intensive Operations (v1.9.0+)
docker run -i --rm \
-e CYBERCHEF_ENABLE_WORKERS=true \
-e CYBERCHEF_WORKER_MAX_THREADS=8 \
-e CYBERCHEF_WORKER_IDLE_TIMEOUT=60000 \
ghcr.io/doublegate/cyberchef-mcp_v4:latestHTTP Transport for Browser/Remote Clients (v1.9.0+)
docker run --rm -p 3000:3000 \
-e CYBERCHEF_TRANSPORT=http \
-e CYBERCHEF_HTTP_PORT=3000 \
-e CYBERCHEF_HTTP_HOST=0.0.0.0 \
-e CYBERCHEF_ALLOWED_HOSTS=localhost:3000,127.0.0.1:3000 \
ghcr.io/doublegate/cyberchef-mcp_v4:latestCYBERCHEF_ALLOWED_HOSTS is new in v2.0.0. DNS-rebinding protection is on by default — with
nothing set the server answers only to localhost, 127.0.0.1 and [::1] — so binding a
non-loopback address means naming the hosts you will reach it by, as the example above does.
Loopback is not an exemption: DNS rebinding exists to reach loopback, by making the victim's
browser resolve an attacker-controlled name to 127.0.0.1. The browser then treats the request as
same-origin, so no preflight is sent and CYBERCHEF_ALLOWED_ORIGINS never comes into it. See
the HTTP transport guide for the full
walkthrough.
Multiple simultaneous clients work from v2.0.0. Before it, the HTTP transport was a single
process-wide instance, so the first client to connect succeeded and every one after it was refused
with Invalid Request: Server already initialized (#36).
Each client now gets its own session and its own MCP server instance. See the
HTTP Transport Guide.
For detailed performance tuning guidance, see the Performance Tuning Guide.
Run the benchmark suite to measure performance on your hardware:
# Install dependencies
npm install
# Generate required configuration
npx grunt configTests
# Run benchmarks
npm run benchmarkThe benchmark suite tests 20+ operations across multiple input sizes (1KB, 10KB, 100KB) in categories including:
Encoding operations (Base64, Hex)
Hashing operations (MD5, SHA256, SHA512)
Compression operations (Gzip)
Cryptographic operations (AES)
Text operations (Regex)
Analysis operations (Entropy, Frequency Distribution)
This project implements comprehensive security hardening with continuous improvements:
Recipe Management System: Save, organize, and reuse multi-operation workflows
CRUD Operations: Create, read, update, delete recipes with versioning
Import/Export: JSON, YAML, URL, and CyberChef format support
Recipe Composition: Nest recipes within recipes for complex workflows
Recipe Library: 25+ curated examples in 5 categories (Cryptography, Encoding, Data Extraction, Forensics, Networking)
Validation Tools: Pre-execution validation with complexity estimation
Testing Tools: Test recipes with sample inputs before deployment
10 New MCP Tools: Complete recipe lifecycle management
See Recipe Management Guide for complete usage documentation
Enhanced Error Handling: Comprehensive error reporting for production debugging
8 Error Codes: Standardized error classification (INVALID_INPUT, MISSING_ARGUMENT, OPERATION_FAILED, TIMEOUT, OUT_OF_MEMORY, UNSUPPORTED_OPERATION, CACHE_ERROR, STREAMING_ERROR)
Rich Context: Detailed debugging information (input size, operation name, request ID, timestamp)
Recovery Suggestions: Actionable recommendations for common issues
Retryable Classification: Automatic distinction between transient and permanent failures
Structured Logging with Pino: Production-ready observability
JSON Logs: Machine-readable logs for monitoring tools (Datadog, Splunk, ELK)
Request Correlation: UUID-based request tracking across operations
Performance Metrics: Duration, throughput, cache hits, memory usage
Configurable Levels: debug, info, warn, error, fatal via LOG_LEVEL environment variable
Automatic Retry Logic: Resilience for transient failures
Exponential Backoff: 1s → 2s → 4s with jitter to prevent thundering herd
Configurable Retries: Default 3 attempts, customizable via CYBERCHEF_MAX_RETRIES
Smart Detection: Automatically retries timeouts, memory issues, network errors
Circuit Breaker: Opens after 5 consecutive failures to prevent cascading issues
MCP Streaming Infrastructure: Progressive results for large operations
Chunked Processing: Memory-efficient handling of 100MB+ inputs
Progress Reporting: Updates every 10MB for long-running operations
14 Supported Operations: Encoding (Base64, Hex), hashing (MD5, SHA family), text operations
Configurable Thresholds: Streaming chunk size and progress interval
Chainguard Wolfi Base Image: minimal, rebuilt daily, zero-CVE baseline
Zero-CVE Baseline: Daily security updates with 7-day SLA for critical patches
70% Smaller Attack Surface: Minimal OS footprint compared to traditional Alpine/Debian images
Non-Root Execution: Runs as UID 65532 (nonroot user), with no package manager in the image
SLSA Build Level 3 Provenance: Verifiable supply chain integrity
Multi-stage Build: -dev variant for compilation, the slim runtime variant for production
Read-Only Filesystem Support: Production-ready immutable deployments
Supports docker run --read-only with tmpfs mount for /tmp
Compliance-ready for PCI-DSS, SOC 2, FedRAMP requirements
Example: docker run -i --rm --read-only --tmpfs /tmp:rw,noexec,nosuid,size=100m cyberchef-mcp
Security Scan Fail Thresholds: Automated vulnerability prevention
Trivy scanner configured with exit-code: '1' in CI/CD
Builds automatically fail on CRITICAL or HIGH vulnerabilities
Prevents vulnerable images from reaching production
Dual SBOM Strategy: Comprehensive supply chain transparency
Part 1: Docker buildx attestations for automated registry scanning (Docker Scout)
Part 2: Trivy CycloneDX SBOM for offline compliance auditing
Both SBOMs attached as release assets for verification
11 of 12 Code Scanning Vulnerabilities Fixed: Comprehensive security hardening completed
CRITICAL: Fixed insecure cryptographic randomness in GOST library - replaced Math.random() with crypto.randomBytes()
HIGH: Addressed 7 ReDoS (Regular Expression Denial of Service) findings across 6 operations
Withdrawn — this protection is no longer present. The fix worked by importing a
SafeRegex.mjs helper into the affected operations. Those operations live under
src/core/operations/, which upstream-sync.yml copies verbatim from upstream, so a
later sync removed every import. The module has been removed rather than left as
dead code claiming a protection it no longer provided.
See the incident record
for the verification and the general rule it establishes: a hand-edit inside
src/core/** is a fix with an expiry date set by the next sync.
All 1,933 Tests Passing: Security fixes validated with comprehensive test suite
See Security Fixes Report for complete details
Dual-Registry Publishing with Attestations: Enhanced security transparency and compliance
Docker Hub: Primary distribution with Docker Scout health score monitoring
GitHub Container Registry (GHCR): Secondary distribution for GitHub ecosystem integration
Both registries receive identical images with full attestation support
Docker Scout Attestations: Build integrity and software transparency
Provenance Attestation (mode=max): Complete build process metadata (builder, materials, recipe) for SLSA Build Level 3 compliance
SBOM Attestation: Automatic Software Bill of Materials generation in SPDX-JSON format
Achieves optimal Docker Scout health score (grade A or B) on Docker Hub
15 points out of 100 in health score calculation - one of the highest-weighted policy categories
Dual SBOM Strategy: Comprehensive software transparency
Docker Attestation SBOM: Attached to image manifest for registry-based validation and docker sbom command
Trivy SBOM Artifact: Standalone CycloneDX file for offline audits and compliance reporting
Both SBOMs include complete dependency tree with version information
Trivy Integration: Container and dependency scanning on every build with fail-fast thresholds
GitHub Security Tab: All findings automatically uploaded as SARIF
Verification: Use docker scout quickview and docker sbom commands to inspect attestations locally
Chainguard Wolfi: Zero-CVE baseline, rebuilt daily
Non-Root Execution: Container runs as UID 65532 (nonroot)
Read-Only Filesystem: Supports --read-only flag for immutable deployments
Minimal Attack Surface: no package manager (apk, wget and curl are absent) and production dependencies only. A BusyBox shell and npm ARE present -- this line said "no shell" until v3.2.0, when measuring the published image showed otherwise. Size a container compromise accordingly.
Health Checks: Built-in container health monitoring
Argon2 OWASP Compliance: Default parameters follow OWASP 2024-2025 recommendations
Type: Argon2id (hybrid side-channel + GPU resistance)
Memory: 19 MiB (OWASP minimum)
Iterations: 2 (OWASP recommended for 19 MiB)
Secure Random Number Generation: All cryptographic operations use crypto.randomBytes() or crypto.getRandomValues()
CVE-2025-64756 Fixed: Updated npm to resolve glob command injection vulnerability
CodeQL Analysis: Continuous code scanning for security vulnerabilities
Weekly Scans: Scheduled scans catch newly discovered vulnerabilities
# Recommended: Run with maximum security options
docker run -i --rm \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=100m \
--cap-drop=ALL \
--security-opt=no-new-privileges \
cyberchef-mcp
# Note: the image already runs as non-root (UID 65532)
# --read-only requires tmpfs mount for /tmp directoryFor detailed information, see:
Security Policy - Vulnerability reporting and security policies
Security Audit - Comprehensive security assessment
Security Fixes Report - Latest vulnerability fixes
Security Fixes Summary - Quick reference guide
The original roadmap scoped 19 releases across 6 phases through August 2027. It was overtaken:
all six phases are complete and the project is at v4.2.0. The table below is kept because it
records what each phase was for; docs/planning/ROADMAP.md is the
live source and has a row per shipped release.
Phase | Releases | Timeline | Focus | Status |
Phase 1: Foundation | v1.2.0 - v1.4.6 | Q4 2025 - Q1 2026 | Security hardening, upstream sync, performance | Completed |
Phase 2: Enhancement | v1.5.0 - v1.7.3 | Q2 2026 | Streaming, recipe management, batch processing | Completed |
Phase 3: Maturity | v1.8.0 - v2.0.0 | Q3 2026 | API stabilization, upstream catch-up, relicensing, v2.0.0 | v2.0.0 Released |
Phase 4: Expansion | v2.2.0 - v2.4.0 | Q4 2026 | Multi-modal (v2.2.0 shipped), protocol currency and transports (v2.3.0 shipped), the tool registry and its first four tools (v2.4.0 shipped) | Complete |
Phase 5: Enterprise | v2.5.0 - v2.7.0 | Q1 2027 | OAuth 2.1, RBAC, audit logging and multi-tenancy (v2.5.0 shipped), horizontal scaling and deployment (v2.6.0 shipped), metrics, tracing and dashboards (v2.7.0 shipped) | Complete |
Phase 6: Evolution | v2.8.0 - v3.0.0 | Q2-Q3 2027 | Edge deployment, AI-native features, v3.0.0 | Completed — and early: v3.0.0 shipped 2026-09 rather than Q3 2027 |
Beyond the plan | v3.1.0 - v4.2.0 | 2026-09 | Conformance against the official suite, magic re-ranking, the arm64 benchmark, PQC identification, retiring the v2 migration surface (v4.0.0), the tool-surface work in v4.1.0, and the dispatch consolidation in v4.2.0 | Shipped, none of it in the original six phases |
External project integration — what it actually produced. The planning tree
(External Project Integration, 30 documents) scoped 80-120 new tools
from 8 security projects. Measuring each against the 504 operations already present cut that hard:
four tools shipped in v2.4.0, drawn on xortool, pwntools, RsaCtfTool, hashcat and John — and
nineteen now exist, twelve added in v3.3.0 and one each in v3.4.0, v3.8.0 and v3.11.0. Four of
the eight projects contributed nothing, because the capability was already here — Magic covers
what Ciphey, Ares and katana's core do, and cryptii's encodings have 26 equivalents among the
operations. The cyberchef-recipes preset corpus remains unbuilt. See
THIRD-PARTY-NOTICES.md for what was taken from where.
See the Full Roadmap for what shipped, and v4 planning for what is being watched for. A major version here exists because the protocol forced one, not because the number was next.
New here? Start with the Tutorial — a guided first hour, from
install to decoding a real sample. Then examples/ for eight runnable scripts that
CI executes on every change, so they cannot drift from the code.
Detailed documentation is organized in the docs/ directory:
User Guide: Detailed installation and client configuration
Commands Reference: List of all available MCP tools and operations
Recipe Management Guide: Complete guide to saving, organizing, and reusing workflows
Upstream Sync Guide: Guide to selective upstream synchronization workflow
Docker Hub Setup Guide: Quick start guide for Docker Hub publishing and attestations
Docker Scout Attestations Guide: Comprehensive guide to supply chain attestations and health scores
Codecov Integration Guide: Coverage analytics, bundle analysis, and test analytics
Architecture: Technical design of the MCP server
Technical Implementation: Implementation details
Performance Tuning Guide: Configuration guide for optimizing performance
Product Roadmap: v1.1.0 → v3.9.0 shipped, with what each release actually found rather than what it planned
v4 planning: one measured plan and nine thin charters — and the measurement that says v4.0.0 is not scheduled, because the MCP draft specification has accumulated no changes since 2026-07-28
Tasks: 500+ implementation tasks organized by release
Development Phases: Sprint breakdowns for each development phase
Release Plans: Individual release specifications (v1.2.0 - v3.0.0)
Project Summary: Internal project overview
Upstream Sync Strategy: Automated CyberChef update monitoring
Security Hardening Plan: Docker DHI, non-root, SBOM generation
Multi-Modal Strategy: Image/binary/audio handling via MCP
Plugin Architecture: Custom operations and sandboxed execution
Enterprise Features: OAuth 2.1, RBAC, audit logging
External Project Integration: Comprehensive planning for v2.0.0+ integrations
Overview: Integration strategy and architecture (4 phases, 12 sprints, 80-120 new tools)
Phase Plans: Foundation, JavaScript Native, Algorithm Ports, Advanced
Sprint Plans: 12 detailed sprint breakdowns with task lists
Tool Integration Plans: Per-tool integration strategies (Ciphey, cryptii, xortool, RsaCtfTool, John, pwntools, katana, recipes)
Technical Guides: Tool registration, algorithm porting, testing, dependencies
Security Tool Reference: Technical documentation for 11 security tools and related projects
cryptii: Modular encoding/decoding system
cyberchef-recipes, cyberchef-server: Related CyberChef projects
john-the-ripper: Password cracking and hash identification
rsactftool, xortool: Cryptanalysis utilities
Security Policy: Security policy and vulnerability reporting
Security Audit: Comprehensive security assessment
Security Fixes Report: Detailed report of 11 vulnerability fixes (ReDoS and cryptographic weaknesses)
Security Fixes Summary: Quick reference for recent security improvements
v2.0.0 Breaking Changes: Comprehensive migration guide for v2.0.0 with deprecation codes, examples, and FAQ
Release Notes v4.2.0: One place to add a meta-tool for the eight of ten that are uniform — 24 dispatch branches down to 16 — and a release whose two central claims were both wrong: the gate it set out to build had existed since v3.7.0, and the two "identical" recipe branches that were not (recipe_execute guards input size, recipe_export was double-encoded by the table) kept theirs. Behaviour preservation proven byte-for-byte through a real client rather than asserted
Release Notes v4.1.0: Registry tools get a navigation path and leave the default surface — the index falls from 41 tools / 44,968 bytes to 23 / 15,620 with nothing made unreachable, and the charter's headline claim turns out to be arithmetically impossible
Release Notes v4.0.0: Retiring the v2 migration surface — the deprecation system, both migration tools and the cyberchef-migrate bin, advertised on every surface for a migration nine minors old
Release Notes v3.11.0: Post-quantum identification (cyberchef_pqc_identify, all eighteen NIST parameter sets), and the thin coverage margin the previous release warned about being hit one release later
Release Notes v3.10.0: runServer() ran on every test import, arming process.exit(1) in 23 files — and fixing it dropped coverage below the gate, because the bug had been executing itself
Release Notes v3.9.0: The release with no charter, scoped from measurement instead: magic candidate re-ranking, one action version per workflow, and the surface figures measured through a real client
Release Notes v3.8.0: Two carried-forward blockers that were never blocked — arm64 benchmarking on hardware CI was already using, and cyberchef_cert_chain
Release Notes v3.7.0: A consistency gate that checked four of eleven files; its operation-count half now discovers its own targets
Release Notes v3.6.0: The benchmark gate measured into existence — a noise floor and a detection curve from a deliberate tunable slowdown, rather than a plausible threshold
Release Notes v3.5.0: Same-host benchmark comparison, and the MCP registry listing that had returned count: 0 since the ownership proofs landed
Release Notes v3.4.0: Three operations that had never worked, and cyberchef_ecdsa_recover
Release Notes v3.3.0: Twelve analysis tools — 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
Release Notes v3.2.0: Every gate checked against its own claim — the benchmark workflow that said it could not fail, and two documents describing a shell-free base image that has a shell
Release Notes v3.1.0: Cache hints at the 2026-era encode seam, and the conformance suite adopted as the oracle
Release Notes v3.0.0: MCP 2026-07-28 conformance and the breaking cleanups it forced — scope filtering wired up, error codes aligned, and an npm publish guard that would have silently skipped this very release
Release Notes v2.10.0: The unified configuration file, announced for v2.0.0 and first actually read here — 61 settings, env over file over default, failing closed on an unknown key
Release Notes v2.9.0: Presented output resolved before the cache, so JSON Beautify stops returning unparseable JSON
Release Notes v2.8.1: CI testing both ends of the supported Node range, rather than one end while the image shipped the other
Release Notes v2.8.0: linux/arm64 alongside amd64, and infrastructure scanning
Release Notes v2.7.0: The image from 643 MB to 453 MB via npm prune --omit=dev, and OpenTelemetry spans on the API only
Release Notes v2.6.0: Startup cut from ~1300 ms to ~185 ms by deferring an import of all 504 operations; health probes and a drain that loses no requests on a rolling update; a Helm chart and Compose file; a 5 s deadline and circuit breaker on calls to the authorization server. Re-scoped: the plan's Redis session store solved a problem MCP 2026-07-28 deleted — the protocol has no sessions. 1,246 MCP tests.
Release Notes v2.5.0: Multi-tenancy completes the Enterprise Features milestone — the cache, recipe store, concurrency pool and audit trail isolated per tenant, with identity taken only from an already-verified token. Plus a rate limiter that had never limited anything since v1.7.0: it was keyed on a per-request UUID, so 1000 requests against a limit of 5 produced 0 denials and 1000 leaked map entries. 1,218 MCP tests.
Release Notes v2.4.0: The tool registry and its first four tools — XOR key length by index of coincidence, De Bruijn patterns compatible with pwntools, hash identification with hashcat modes, and four RSA attacks. No plugin loader, with the node:vm measurement that rules one out. Three documents corrected that described work nobody had done.
Release Notes v2.3.0: Protocol revision 2026-07-28 on stdio and HTTP, a socket transport, npm distribution unblocked, 17 image operations returning a pooled backing ArrayBuffer — unrelated bytes — instead of the image, Add Text To Image working for the first time, the coverage gate raised from 75/70/90/75 to 95/88/96/96, 1,023 MCP tests
Release Notes v2.2.0: Images and audio as content blocks (Generate QR Code returned "" and never worked), tool annotations on all 527 tools, prompts and resources, LM Hash off OpenSSL, unknown arguments rejected instead of silently defaulted, 955 MCP tests
Release Notes v2.1.0: Tool-list hierarchy (~97% smaller tools/list), Zod 4 schema fix, all 10 flow-control operations working, AES and 62 other toggleString operations fixed, logs to stderr, 60s shutdown hang removed, tutorial + 8 runnable examples
Release Notes v2.0.0: Upstream v11.4.0 (504 operations), GPL-3.0-or-later relicense, Node 24 floor, per-session HTTP transport (#36), 272 security findings closed, 757 MCP tests
Open-alert disposition: Every Dependabot and code-scanning alert — fixed, suppressed with a justification, or dismissed with a reason
Release Notes v1.9.0: MCP streaming, worker thread pool, HTTP transport, upstream v10.20.0, security updates, 689 tests
Release Notes v1.8.0: Breaking changes preparation - deprecation warnings, migration preview tool, v2.0.0 compatibility mode
Release Notes v1.7.3: Reference documentation and v2.0.0 integration planning - 42 new documentation files, comprehensive security tool reference
Release Notes v1.7.2: CI improvements, test expansion, documentation updates - enhanced workflows, 150 new tests, corrected metrics
Release Notes v1.7.1: Repository cleanup and workflow enhancements - removed 88 unused files, enhanced upstream sync
Release Notes v1.7.0: Advanced features - batch processing, telemetry, rate limiting, cache enhancements, resource quotas
Release Notes v1.6.2: Technical debt fixes - ESLint errors resolved, ENABLE_WORKERS default corrected
Release Notes v1.6.1: Comprehensive test coverage (311 tests, 78.93% coverage) and Codecov integration
Release Notes v1.6.0: Recipe management system with CRUD operations, import/export, and curated library
Release Notes v1.5.0: Enhanced error handling, structured logging, automatic retry, streaming infrastructure
Release Notes v1.4.6: Sprint 1 Security Hardening - Chainguard distroless migration, zero-CVE baseline, read-only filesystem support
Release Notes v1.4.5: Supply chain attestations and documentation reorganization
Release Notes v1.4.4: Docker Hub build fix and 12 security vulnerability fixes
Release Notes v1.4.3: Dependency resolution and Node.js 22 compatibility
Release Notes v1.4.2: CI/CD improvements and zero-warning workflows
Release Notes v1.4.1: Security patch - 11 Code Scanning vulnerabilities fixed
Release Notes v1.4.0: Performance optimization with caching, streaming, and resource limits
Release Notes v1.3.0: Upstream sync automation with comprehensive testing
Release Notes v1.2.6: nginx:alpine-slim optimization for web app
Release Notes v1.2.5: Security patch with OWASP Argon2 hardening
Release Notes v1.2.0: Security hardening release
Release Notes v1.1.0: Security fixes and Node.js 22 compatibility
Release Notes v1.0.0: Initial MCP server release
If you want to modify the server code without Docker:
Use the pinned Node version. .nvmrc pins 26 (matching engines: >=26 <27 and every
CI workflow), so nvm use / fnm use selects it. Worth doing rather than assuming: through
v4.0.0 this file said 24 while the floor was already 26, so version managers quietly
selected a Node below the floor for an entire release.
nvm use # or: fnm use
node --version # expect v26.xInstall Dependencies:
npm installGenerate Config: (Required to build the internal operation lists)
npx grunt configTestsRun Server:
npm run mcpThis project uses GitHub Actions to ensure stability and security:
Core Development Workflows:
MCP Server CI (core-ci.yml): Tests the underlying CyberChef logic and configuration generation on Node.js 26
Docker Build (mcp-docker-build.yml): Builds, verifies, and security scans the cyberchef-mcp Docker image
Pull Request Checks (pull_requests.yml): Automated testing and validation for pull requests
Performance Benchmarks (performance-benchmarks.yml): Automated performance regression testing on code changes (v1.4.0+)
Code Quality & Coverage:
Codecov Integration: Comprehensive code quality analytics with three distinct components
Coverage Analytics: Automated coverage tracking with V8 provider and status checks on pull requests
Project coverage threshold: 95% (codecov.yml)
Patch coverage threshold: 90% for new code
Multiple coverage formats: lcov, JSON, HTML, Cobertura
Component-level tracking: MCP Server, Core Operations, Node API
Bundle Analysis: Webpack bundle size tracking and visualization via @codecov/webpack-plugin
Automated bundle size change detection in pull requests
Historical bundle size trends and optimization insights
Dry-run mode for local development
Test Analytics: JUnit XML test result reporting and analysis
Test performance tracking over time
Flaky test detection
Test execution time monitoring
Configuration: codecov.yml, coverage flags, thresholds, PR commenting
See Codecov Integration Guide for complete setup and usage documentation
Security & Release Workflows:
Security Scan (security-scan.yml): Trivy vulnerability scanning, SBOM generation, weekly scheduled scans
CodeQL Analysis (codeql.yml): Automated security scanning for code vulnerabilities (CodeQL v4)
Release (mcp-release.yml): Publishes Docker image to GHCR with SBOM attachment on version tags (v*), automatically creates GitHub releases
Upstream Sync Automation (v1.3.0+):
Upstream Monitor (upstream-monitor.yml): Monitors GCHQ/CyberChef for new releases weekly (Sundays at noon UTC), creates GitHub issues for review
Upstream Sync (upstream-sync.yml): Selective file synchronization workflow - copies only src/core/operations/*.mjs files, prevents restoration of deleted web UI components, creates PR for review
Rollback (rollback.yml): Emergency rollback mechanism with state comparison and ref-proj guidance
All workflows use the latest CodeQL Action v4 for security scanning and SARIF upload.
# Run all tests (requires Node.js >=26 <27; 241 Node-API + 2,289 operation tests)
npm test
# Run MCP validation test suite (1,728 tests across 75 files, with Vitest)
npm run test:mcp
# Run MCP tests with coverage report
npm run test:coverage
# Run performance benchmarks (v1.4.0+)
npm run benchmark
# Test Node.js consumer compatibility
npm run testnodeconsumer
# Lint workflows (matches the CI gate)
actionlint .github/workflows/*.yml
# Lint code
npm run lintTest Coverage: The MCP server maintains comprehensive test coverage:
1,728 MCP tests across 75 suites, plus 241 Node-API tests, 2,289 operation tests and 9 runnable examples executed by CI
Coverage thresholds (vitest.config.mjs): 96% lines, 95% statements, 89% branches, 96% functions, with src/node/lib/** held separately at 99 lines / 99 statements / 94 branches / 100 functions
Current coverage: 96.44% lines, 95.50% statements, 96.84% functions, 89.88% branches (thresholds 96/89/96/95, lines/branches/functions/statements)
Note: individual suite names are not listed here because the list went stale three times;
ls tests/mcp/*.test.mjs is authoritative.
Contributions to the MCP adapter are welcome! We appreciate:
Bug Reports: Open an issue with detailed steps to reproduce
Feature Requests: Check Roadmap first, then open an issue
Pull Requests: See Tasks for areas needing work
Documentation: Improvements to guides and examples are always welcome
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes and test thoroughly
Commit with conventional commit messages (feat:, fix:, docs:, etc.)
Push to your fork and submit a pull request
For contributions to the core CyberChef operations, please credit the original GCHQ repository.
Original CyberChef: GCHQ/CyberChef
MCP Fork: doublegate/CyberChef-MCP
Container Registries:
Docker Hub (Primary): parobek/cyberchef-mcp - With Docker Scout health scores and attestations
GHCR (Secondary): ghcr.io/doublegate/cyberchef-mcp_v4 — v4.x. The package name carries the major, so each line keeps its own image and is not superseded in place: v3.x stays at cyberchef-mcp_v3, v2.x at cyberchef-mcp_v2.
GHCR (v1, frozen): ghcr.io/doublegate/cyberchef-mcp_v1
Remains pullable; receives security-only patches on the v1.9.x line until ~March 2027.
Apache-2.0, not GPL-3.0-or-later.
Still has the single process-wide HTTP transport that #36 reported, so only one HTTP client can connect at a time. Fixed in v2.x, not backported.
npm Package: cyberchef-mcp — published from
CI on each version tag since v2.5.0. npx cyberchef-mcp runs the server without installing it;
npm install -g cyberchef-mcp installs the cyberchef-mcp bin. The package is the artefact the
MCP registry listing points at, which is why the release job waits for npm to serve it before
publishing that listing.
Glama Listing: doublegate/CyberChef-MCP
— an independent third-party directory that starts the server and introspects it rather than
reading its README, and scores quality and maintenance from what it finds. Ownership is declared
in glama.json at the repository root. The badges above and below render its
current scores live; they are deliberately not transcribed into this file, because a number
copied out of a service is a number that rots.
Issue Tracker: GitHub Issues
If you find this project useful, consider supporting its development:
As of v2.0.0, CyberChef-MCP is licensed under GPL-3.0-or-later. Versions 1.9.x and earlier remain Apache-2.0 and are unaffected.
Upstream CyberChef is released under the
Apache 2.0 Licence and is covered by
Crown Copyright.
Files inherited from upstream keep their Apache-2.0 headers; the full text is preserved in
LICENSE.Apache-2.0. This is not a relicensing of GCHQ's code — it is the
combined work that is GPLv3, which Apache-2.0's one-way compatibility with GPLv3 permits.
The change was forced by v2.0.0 incorporating algorithms from GPL-licensed reference tools:
katana is GPL-3.0-or-later (ruling out GPLv2) and John the Ripper is GPL-2.0-or-later, while
Apache-2.0 is compatible with GPLv3 but not GPLv2. GPL-3.0-or-later is the only licence that
admits all three. The reasoning is recorded in
ADR 0001, and per-component attribution is in
THIRD-PARTY-NOTICES.md.
What this means for you: running CyberChef-MCP — including serving it over HTTP — carries no obligation, as GPLv3 has no network-use clause. Distributing a derivative of it does: that must also be GPLv3. If your policy precludes GPLv3, stay on the v1.9.x line, which remains Apache-2.0 and receives security-only patches through its LTS window.
Run one of this server's analysis tools -- analyses a CyberChef operation cannot express, such as recovering an XOR key length, breaking a classical cipher, identifying a hash, validating an X.509 chain or identifying a post-quantum key. List them with cyberchef_categories, get a schema with cyberchef_describe_operation, then run it here. These are NOT operations and cannot be used in a cyberchef_bake recipe.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Analysis tool name, without the `cyberchef_` prefix, e.g. "hash_identify", "xor_key_length", "pqc_identify". Either form is accepted. | |
| arguments | No | Arguments for the tool, matching the schema cyberchef_describe_operation returns for it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false). The description adds context the annotations cannot: this is a dispatcher onto sub-analyses rather than a single fixed operation, and its argument shape varies per selected tool. It stops short of describing return format or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose in the first clause and keeps the workflow and exclusion rules tight. The five-item example list is slightly long but each example maps to a distinct analysis class, so it earns most of its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a dispatcher tool with full schema coverage, annotations covering the safety profile, and no output schema, the description supplies everything an agent needs: what it does, how to discover valid tools, how to obtain per-tool argument schemas, and the key exclusion. No return-value description is required since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema, including that `tool` accepts either form and that `arguments` matches the schema from cyberchef_describe_operation. The description largely repeats that routing advice, adding no syntax or format detail beyond the structured fields — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('run one of this server's analysis tools') and distinguishes it sharply from siblings by declaring 'These are NOT operations and cannot be used in a cyberchef_bake recipe.' Concrete examples (XOR key length, classical cipher, hash ID, X.509 chain, post-quantum key) make the scope unambiguous without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit three-step workflow — 'List them with cyberchef_categories, get a schema with cyberchef_describe_operation, then run it here' — and a clear negative rule against using it in cyberchef_bake recipes. Both when-to-use and when-not-to-use are stated, with the alternative tools named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a CyberChef recipe. Use this for complex chains of operations.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The input data | |
| recipe | Yes | List of operations to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as destructive and potentially open-world, but the description itself adds no behavioral context beyond 'execute.' It does not mention whether output is returned synchronously, whether recipes can trigger external side effects, or what operational consequences the destructiveHint refers to. Since it adds no insight beyond the annotations, it under-delivers for an execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences with no wasted words. It front-loads the main action and follows with a brief usage hint. Nothing repeats the schema, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, potentially destructive behavior, and broad execution capabilities, this description is too thin. It does not describe return values, error behavior, execution limits, or how it differs from related tools like cyberchef_recipe_execute. The schema covers inputs well, but not the execution context an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the input and recipe parameters, including the recipe's op/args shape and a pointer to cyberchef_describe_operation. The tool description adds no parameter-level detail, so it earns the baseline score of 3 rather than being penalized for a schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a concrete action and resource: it executes a CyberChef recipe. It also adds a usage scope by mentioning 'complex chains of operations.' However, it does not explicitly distinguish this from sibling tools like cyberchef_recipe_execute, which may also sound recipe-related, so it is not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this for complex chains of operations' provides a clear, explicit when-to-use context. It stops short of naming exclusions or alternatives such as cyberchef_magic or cyberchef_recipe_execute, so there is no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute multiple CyberChef operations in batch (parallel or sequential mode). Supports partial success.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Execution mode | parallel |
| operations | Yes | Array of operations to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true and readOnly=false, so the description does not need to restate that this is a mutating batch operation. It adds 'supports partial success,' which is useful, but does not explain failure semantics, side effects, ordering guarantees, or what happens to partially completed batches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that front-loads the core purpose and includes the key nuance of partial success. Every part earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description does not explain what the tool returns, how results are reported, how failures are surfaced, or how partial success manifests. For a batch execution tool with destructive potential, an agent needs more behavioral context to invoke it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, and both properties have descriptions. The description mentions parallel/sequential mode, but the schema already documents the enum and default, so the description adds minimal new meaning beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes multiple CyberChef operations in batch and identifies the two execution modes. It is specific enough to distinguish from most sibling tools that handle single operations, though it does not explicitly contrast with recipe_execute or bake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'execute multiple operations in batch' implies this tool is for grouping operations rather than calling them one at a time, but it gives no explicit guidance on when to choose this over alternatives such as recipe_execute, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the operation result cache.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description contradicts annotations: 'Clear' is a mutating action, but readOnlyHint is true. While idempotentHint and destructiveHint align with a cache-clear operation, the readOnly contradiction is significant and confusing for an agent deciding whether this tool is safe to invoke.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It states the action and target in the fewest possible words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter operation, a one-line description is a minimum viable definition. However, it does not explain what 'operation result cache' is, what consequences clearing it has, or how it relates to cyberchef_cache_stats, and the readOnlyHint contradiction leaves the overall context inconsistent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the empty input schema is fully self-explanatory. The description does not need to add parameter-level detail; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Clear') and a specific resource ('the operation result cache'), making the tool's action immediately clear. It also naturally distinguishes this tool from the sibling cyberchef_cache_stats: one clears, the other reports stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to clear the cache versus inspecting it with cyberchef_cache_stats, nor does it mention any prerequisites or side effects. Usage context is only implied by the verb 'Clear'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cache statistics including hits, misses, size, and items.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description is consistent with them. It adds the list of reported metrics but does not disclose extra behavioral details such as whether statistics are cumulative or reset by cache_clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler; every word contributes to meaning and the key scoping phrase 'cache statistics' is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only utility the description is nearly complete, listing the essential output fields. It falls slightly short of 5 because it does not clarify units or semantics for 'size,' which could mean bytes, entries, or another measure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('cache statistics') and enumerates the exact metrics returned (hits, misses, size, items). This clearly distinguishes it from siblings like cyberchef_cache_clear (mutation) and cyberchef_worker_stats (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over alternatives or when not to use it. While the name and read-only annotations imply it is for inspection, the description does not state exclusions or mention cache_clear/worker_stats as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List CyberChef's operation categories with counts and examples. Start here to browse what this server can do, then use cyberchef_list_operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| categories | Yes | |
| analysisTools | No | |
| totalOperations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only that results include counts and examples, which is mild extra value; with an output schema present there is little more it needs to disclose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and resource, followed by the routing hint. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only browsing tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what it returns and where it fits in the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to explain; the baseline for a parameterless tool is 4. The description correctly implies no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('List') plus resource ('CyberChef's operation categories') with added scope detail (counts and examples). It also names the sibling cyberchef_list_operations, letting an agent place it relative to the operation-listing tool without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions itself as the entry point ('Start here to browse what this server can do') and names the follow-up action with its tool ('then use cyberchef_list_operations'). This is unambiguous routing guidance, not inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full argument schema, defaults and types for one or more operations. This is what you need before calling cyberchef_bake with a new operation.
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | One operation name, or several, e.g. "AES Encrypt" or ["Gzip", "To Base64"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying what information the tool returns (schema, defaults, types) and why it matters for baking operations. This goes beyond simply restating the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The core value proposition is front-loaded, and the practical usage note immediately follows, making it easy for an agent to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, high schema coverage, and read-only annotations, the description is largely complete. It states the input, the output content, and the usage context, though it does not mention error behavior for unknown operation names—a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the operations parameter with examples and types, so description-level parameter explanation is not critical. The description reinforces that one or more operation names are accepted and that this is for new operations, but it does not add significant semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it returns the full argument schema, defaults, and types for one or more operations. It also distinguishes itself from cyberchef_bake by positioning this as a required prerequisite step, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: before calling cyberchef_bake with a new operation. It does not enumerate alternatives or exclusions, but the workflow context is clear enough to guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the operations in one category, with a one-line summary of each. Use cyberchef_describe_operation for full argument schemas.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category name, e.g. "Encryption / Encoding", "Hashing", "Extractors" |
| Name | Required | Description |
|---|---|---|
| next | Yes | |
| category | Yes | |
| operations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying that results are one-line summaries and that deeper argument details are intentionally deferred to another tool, which shapes agent expectations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: the first states the operation and output, the second routes to the relevant sibling. The most important scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with one documented parameter and an output schema, the description covers what an agent needs to select and invoke it correctly. It also names the natural follow-up tool for richer detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'category' parameter is already documented with examples. The description adds minimal semantic value beyond restating the category concept, so it appropriately relies on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), a resource ('operations'), and a scoping dimension ('in one category') plus the output format (one-line summary). It also differentiates from cyberchef_describe_operation by explicitly directing full argument schema lookups there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this tool for category-scoped operation lists with summaries. It names the alternative tool for a different need ('Use cyberchef_describe_operation for full argument schemas'), effectively telling the agent when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Magic operation attempts to detect various properties of the input data and suggests which operations could help to make more sense of it.OptionsDepth: If an operation appears to match the data, it will be run and the result will be ana...
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Layers of encoding to unwrap. Default 3 handles the usual nesting (base64-then-gzip); raise only if output is still encoded. Cost grows fast. | |
| input | Yes | The input data to process | |
| intensive_mode | No | Also brute-force XOR, bit rotations and encodings, not just detect them. Finds single-byte XOR; slow, and only the first 100 bytes are tried. | |
| extensive_language_support | No | Compare against 284 languages instead of ~40. Usually widens the match list without sharpening it; the language result is an estimate either way. | |
| crib_known_plaintext_string_or_regex | No | Regex a decoding must match to be reported. The most effective filter when you know any of the plaintext -- a flag prefix, a header, an expected word. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that matching operations will actually be run and their results analyzed, which is useful behavioral context beyond the readOnly/idempotent annotations. The text is truncated at 'the result will be ana...', so the full behavior is not visible; this limits the transparency score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is informative, but the text is poorly formatted with run-together content like 'it.OptionsDepth:' and appears truncated. It is not excessively long, but the structure is messy enough to reduce clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should say more about what Magic returns—such as suggested recipes, confidence levels, or decoded output—but it only says it 'suggests which operations.' The parameter docs are strong, yet the missing output expectations and truncated description leave a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has rich, behavior-oriented documentation such as cost growth, 100-byte limits, and language count trade-offs. The tool description adds little beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: detect properties of the input data and suggest operations to make sense of it. This clearly identifies the tool's function, though it does not explicitly differentiate it from sibling detection tools like cyberchef_entropy_scan or cyberchef_hash_identify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than explicit: an agent can infer this is for unknown-format input that needs automatic analysis. However, there is no direct guidance about when to prefer Magic over alternatives like baking a known recipe or using a more targeted identifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current resource quota information including concurrent operations and data sizes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful context that the information is 'current' and includes concurrent operations and data sizes, but it does not describe the output shape or any refresh/accuracy behavior. With annotations carrying the main burden, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight, front-loaded sentence: 'Get current resource quota information' immediately conveys the action and subject, and 'including concurrent operations and data sizes' adds valuable scope without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only info tool, the description plus annotations are nearly sufficient for an agent to call it correctly. The only notable gaps are the lack of explicit usage guidance relative to similar stats tools and the absence of any indication about return format, but the tool is simple enough that these are minor rather than blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema is empty, so there is nothing for the description to clarify. Schema description coverage is effectively 100%, and the baseline for zero-parameter tools applies. The description adds no parameter-specific meaning, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get'), a distinct resource ('resource quota information'), and the content scope ('concurrent operations and data sizes'). It clearly identifies what the tool does and separates it from cache/stats/worker sibling tools by naming the quota resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies when to use this tool: when current quota information is needed. It does not explicitly say when to prefer it over related tools like worker_stats or cache_stats, nor does it mention any exclusions. For a zero-parameter read tool this is minimally adequate but leaves the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new recipe with multiple operations.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Recipe name | |
| tags | No | Recipe tags | |
| author | No | Author email | |
| metadata | No | ||
| operations | Yes | List of operations | |
| description | No | Recipe description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) establish that this is a non-idempotent write that does not destroy data, and the description's 'Create' verb is consistent with that. However, beyond confirming the write, the description discloses no behavioral context: it does not say what happens on duplicate names, whether the recipe is persisted server-side, whether operations are validated at creation time, or what the agent should expect in return. With idempotentHint=false, duplicate-handling behavior is especially relevant and is left entirely unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single seven-word sentence with the verb front-loaded and zero filler. It is efficiently structured and immediately readable. However, it is arguably thinner than the tool's complexity warrants, which slightly undercuts the conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 6 parameters, nested objects, no output schema, and 39 siblings including 9 recipe-* tools, yet the description provides only one sentence. With no output schema, the agent cannot infer the return value or success indicators, and the description does not cover them. Missing context around duplicate handling, validation behavior, and relationship to recipe_validate/recipe_test/recipe_import leaves the description incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, above the 80% threshold, so the schema carries most of the parameter documentation (name, tags, author, operations, description all have descriptions). The description's 'multiple operations' merely echoes the schema's 'List of operations' field and adds no new semantics. The few uncovered details, such as the inner metadata fields (category, complexity, estimatedTime) and the args/recipe structure inside operations items, are not compensated for by the description, keeping this at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('a new recipe'), and the phrase 'with multiple operations' adds a scoping detail that aligns with the required operations parameter. It is clearly distinguishable from siblings like recipe_delete, recipe_get, and recipe_update by the create verb, though it does not explicitly name or differentiate from recipe_import, which could also be used to bring recipes in.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many recipe-related siblings (recipe_validate, recipe_test, recipe_import, recipe_update). An agent gets no hints about workflow ordering, such as whether to validate operations before creating, or which sibling handles modifications to an existing recipe. Nothing in the description establishes selection criteria among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a recipe by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recipe UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the agent knows this operation mutates and can be repeated. The description adds no extra behavioral context beyond what the annotations provide, such as whether deletion is permanent, whether related data is affected, or whether authorization is required. Because the annotation already carries the core safety signal, the description is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that states the operation and parameter without waste. It is front-loaded and easily scanned. It could earn a 5 only by adding a bit more practical context, but for its brevity it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and this is a destructive operation, the description could usefully mention what the response looks like (e.g., success confirmation or deleted recipe) or any non-obvious behavior such as idempotent deletion of an already-missing recipe. The annotations cover the destructive and idempotent nature partially, but the description itself is minimal. It is adequate for a simple one-parameter delete but leaves room for more complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter (id) with a format and pattern, and the schema description coverage is 100%, so the schema does the heavy lifting. The description only says 'by ID' and does not add anything concrete about the semantics of id beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a recipe by ID' uses a specific verb ('Delete') and names the resource ('recipe') and the identifying parameter ('ID'). It is clear at a glance which operation is performed and on what entity, and the presence of sibling tools like cyberchef_recipe_get, cyberchef_recipe_create, and cyberchef_recipe_update makes this description sufficiently distinct as the deletion counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a recipe should be removed by its UUID, but it does not explicitly state when to use it versus alternatives or mention any restrictions or side effects such as whether the deletion is permanent or cascades. There is no explicit when-not-to-use guidance, so an agent is left to infer the usage context from the verb and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a saved recipe with input data.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recipe UUID | |
| input | Yes | Input data to process |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, readOnlyHint=false, and idempotentHint=false, and the description adds no behavioral context beyond them. It does not disclose side effects, whether input is irreversibly transformed, quota consumption, or what 'execute' entails — all relevant given the destructive flag. There is no contradiction with the annotations, but the description contributes no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single eight-word sentence with the verb front-loaded and zero filler words. It is efficient and scannable, though slightly under-sized for a tool carrying a destructive flag and a near-identical sibling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should convey what the call returns on success, but it is silent on that. With destructiveHint=true and a large sibling set that includes cyberchef_bake and cyberchef_recipe_test, the description is too thin for an agent to invoke it confidently without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the schema already documents 'id' as 'Recipe UUID' and 'input' as 'Input data to process'. The description's phrase 'with input data' merely restates the schema, so it adds no parameter-level meaning; the high-coverage baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Execute) and resource (a saved recipe) along with the input payload, making the core action unambiguous. The qualifier 'saved' distinguishes it from recipe-management siblings like cyberchef_recipe_create/get/delete, but it does not explicitly differentiate it from the close sibling cyberchef_bake, so the distinction is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, exclusions, or mention of alternatives. An agent cannot tell from this text whether to choose cyberchef_recipe_execute or cyberchef_bake (or cyberchef_recipe_test), since the selection criteria between saved-recipe execution and inline baking are never stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a recipe to various formats (json, yaml, url, cyberchef).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recipe UUID | |
| format | Yes | Export format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds little beyond the format list and does not disclose what the export returns or whether it has side effects, though no contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundancy. It immediately communicates the action, target, and supported formats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only export operation, the description and schema cover the necessary inputs, and annotations cover the safety profile. However, there is no output schema and no note describing whether the export returns file contents, a URL, or another representation, which leaves a meaningful gap for agents using the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with 'id' described as 'Recipe UUID' and 'format' as 'Export format' with a full enum. The description's format list largely restates the enum, adding no significant new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Export'), a specific resource ('a recipe'), and enumerates the target formats (json, yaml, url, cyberchef). This clearly distinguishes the tool from siblings like cyberchef_recipe_import and cyberchef_recipe_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear, but the description does not explicitly say when to use this tool versus alternatives such as recipe_get or recipe_import. The word 'Export' implies its niche, but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a recipe by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recipe UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds no further behavioral details such as not-found behavior, response shape, or permission requirements, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundant wording. Every word contributes to the basic purpose of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read-only getter, and the schema plus annotations cover most invocation needs. The absence of an output schema and any mention of what fields the returned recipe contains is a minor gap, but not enough to make the description inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'id' is already described as 'Recipe UUID' with a UUID format and pattern. The description does not add meaningful parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('a recipe'), and the identifying mechanism ('by ID'). It is distinguishable from recipe_list and recipe_create, but it does not explicitly differentiate itself from recipe_export or recipe_execute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies this tool should be used when the agent already has a recipe UUID and wants the stored recipe. However, no alternative tools are mentioned and no explicit when-to-use or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a recipe from various formats.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Recipe data to import | |
| format | Yes | Import format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is a non-destructive, state-changing operation, so the description does not need to restate that. It adds the fact that the recipe can come from external formats, but it does not disclose whether the import creates a new recipe, overwrites an existing one, or validates input first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, making it concise and easy to scan. It is slightly too terse to carry meaningful selection guidance, but structurally it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a fully descriptive schema and enum, the minimal description plus schema is enough for an agent to construct a valid call. However, the lack of mention of the import's effect or return value keeps it at only a minimum-viable level, especially with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions and an enum for format, so the schema does the heavy lifting. The description's 'various formats' adds no meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action ('Import') and the target resource ('a recipe'), and 'from various formats' conveys the operation's scope. It does not explicitly differentiate from sibling tools like recipe_create or recipe_export, so it is clear but not sharply distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose import over alternatives such as recipe_create, recipe_export, or recipe_validate. 'From various formats' implies existing serialized recipe data, but the description never states exclusions or when to use a different sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all recipes with optional filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag | |
| limit | No | Maximum results | |
| offset | No | Pagination offset | |
| search | No | Search in name/description | |
| category | No | Filter by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful scoping context by stating it lists all recipes with optional filtering, but it does not disclose pagination defaults, response shape, or ordering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The primary action, 'List all recipes', is front-loaded and the filtering detail is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema documents all five optional parameters and the annotations cover read-only and non-destructive behavior. However, with no output schema, the description does not clarify what a returned recipe entry looks like, whether results are paginated by default, or what ordering is applied. This is minimally adequate but leaves some operational ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with parameters like 'Filter by tag', 'Maximum results', and 'Pagination offset' already self-explanatory. The tool description's mention of optional filtering adds no meaningful semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the concrete verb 'List' and identifies the resource 'recipes', while also noting optional filtering. It is clear, but it does not explicitly distinguish this tool from sibling tools like cyberchef_recipe_get or cyberchef_list_operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives such as cyberchef_search, cyberchef_recipe_get, or cyberchef_list_operations. The phrase 'optional filtering' implies some use cases, but the description lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a recipe with sample inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | Yes | Recipe to test | |
| testInputs | Yes | Array of test inputs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not required to restate those. The description adds the basic behavior that the tool runs a test with sample inputs, which is already clear from the name and schema. It does not disclose anything beyond that, such as what 'testing' does differently from executing, what the result payload contains, or side effects like caching. That is acceptable given annotations but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence: 'Test a recipe with sample inputs.' There is no wasted wording, and the core action and object are front-loaded. It could earn a 5 if it also gave a one-line usage hint, but as written it is concise and structured enough for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent tool with full schema coverage and no output schema, the description is minimally sufficient. However, it lacks contextual completeness in one important respect: given sibling names like cyberchef_recipe_validate, cyberchef_bake, and cyberchef_recipe_execute, an agent might not understand what 'test' uniquely offers. The description does not clarify the expected outcome of a test or how it differs from validation/execution, so the tool's role in the larger toolkit is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents recipe and testInputs as an object containing a name and operations array and an array of test values. The description adds minimal semantic value beyond 'sample inputs' as the purpose of testInputs. It does not explain the nested operation structure, the meaning of args, or constraints on test inputs, but the schema already carries that burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Test a recipe with sample inputs' states a specific verb ('test') and resource ('recipe'), and the parameter names (recipe, testInputs) reinforce that this tool validates a recipe against sample inputs. While it is reasonably clear, it does not explicitly contrast itself with sibling tools like cyberchef_validate or cyberchef_bake, so it gets a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you have a recipe and sample inputs and want to test whether the recipe produces expected results. However, it does not explicitly say when to prefer this over cyberchef_recipe_validate (validation of recipe structure) or cyberchef_bake (executing a recipe against data). It gives no 'use X instead' guidance, so it is adequate but lacks explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing recipe.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recipe UUID | |
| name | No | New recipe name | |
| tags | No | New tags | |
| metadata | No | ||
| operations | No | New operations | |
| description | No | New description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, idempotentHint=true, and readOnlyHint=false, but the description adds no behavioral context beyond the generic word 'Update.' It does not disclose whether this is a partial update (only provided fields change) or a full replacement, what data may be overwritten, or any side effects. With a destructive tool and no additional behavioral disclosure, the description underperforms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no waste, but it is under-specified for a tool with six parameters and nested objects. It is concise without being informative. Other similarly short descriptions that listed updatable fields have been graded slightly higher because they front-load useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, nested objects, a destructive annotation, and no output schema, the description is far too thin. It does not explain update semantics, which fields can change, whether partial updates are supported, or anything about expected behavior after invocation. An agent would need to rely entirely on the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, and the schema already documents parameters such as id, name, tags, metadata, operations, and description. The description itself adds no parameter meaning, but the high schema coverage means the baseline applies. No compensation is needed, though the description could have noted that only supplied optional fields are updated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Update an existing recipe.' It clearly identifies the tool as a modification operation on a recipe, and 'existing' subtly distinguishes it from create and delete siblings. However, it does not explicitly name sibling tools or state the scope of what can be updated, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus alternatives like cyberchef_recipe_create, cyberchef_recipe_delete, or cyberchef_recipe_get. There are no exclusions, prerequisites, or context about why an agent would choose this update tool over related recipe operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a recipe without saving it.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | Yes | Recipe to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety burden is covered. The description adds the no-save behavior, which is useful, but says nothing about what 'validate' returns or how it signals failure, so some behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, with no filler or duplicated schema information. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with no output schema, the description does not explain validation behavior (syntax only vs. deep operation/arg validation), error signaling, or whether the recipe is normalized/reported. The nested recipe structure and many sibling tools increase the need for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, including the recipe property marked as 'Recipe to validate', so the description doesn't need to restate parameter meaning. It adds no operational detail about the nested operations/args structure, but baseline 3 is appropriate since schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('validate') and resource ('recipe') and immediately qualifies that no save occurs, which separates it from create/update/execute siblings. It doesn't explicitly distinguish from recipe_test, so not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without saving it' implies use for non-persistent validation, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternative tools like recipe_test or recipe_execute. The usage context is only inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for available CyberChef operations. Returns names and one-line summaries; follow up with cyberchef_describe_operation for argument schemas.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| detailed | No | Return the full operation entries instead of summaries. Costs roughly 8x the bytes; prefer cyberchef_describe_operation for the few operations you want. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral detail by stating the result shape (names and one-line summaries) and signaling that full schemas are intentionally deferred to another tool. This is meaningful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core action is front-loaded, the return behavior is stated, and the recommended next step is included. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool with fully documented parameters, the description is nearly sufficient. It covers purpose, return content, and follow-up. The main gap is the lack of explicit positioning against cyberchef_list_operations, which could leave an agent slightly uncertain about which search/list tool to choose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters clearly. The description adds no extra parameter-level meaning, such as how 'query' matches against operations or when 'detailed' should be set. Baseline 3 applies because the schema carries the burden successfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('available CyberChef operations'), and clarifies that it returns names and one-line summaries. It distinguishes itself from cyberchef_describe_operation by pointing to that tool for schemas, but it does not explicitly differentiate itself from the similar-sounding cyberchef_list_operations, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use it to search for operations, and follow up with cyberchef_describe_operation for argument schemas. It does not explicitly say when to prefer this over cyberchef_list_operations or cyberchef_categories, but the search-focused guidance is still useful and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export collected telemetry metrics. Returns anonymized usage statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export format | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds one behavioral detail beyond that: the returned data is anonymized. This is useful context but not extensive; no rate limits, auth requirements, or output-shape caveats are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, both functional: the first states the operation, the second adds the anonymization detail. No fluff, no repetition of the schema, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, complete schema coverage, and safety annotations, the description is nearly sufficient. It does not explain what the 'json' vs 'summary' formats return, but the schema defines those options. The only meaningful omission is lack of differentiation from sibling stats tools, which is more a usage-guidance gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single 'format' parameter 100% with an enum, default, and description. The tool description adds nothing about the parameter, so the schema carries the full weight. This aligns with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export') and resource ('collected telemetry metrics'), and the second sentence clarifies what the result is ('anonymized usage statistics'). This clearly distinguishes it from the many baking/recipe tools in the sibling list, though it does not explicitly contrast with the other stats-like tools (e.g., cyberchef_worker_stats, cyberchef_cache_stats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states only what the tool does and gives no guidance about when to use it versus alternatives. There is no mention of scenarios, exclusions, or a preferred sibling for similar telemetry/stats needs, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get worker thread pool statistics including thread count, utilization, and completed tasks. Only available when ENABLE_WORKERS=true.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations by specifying the availability condition (ENABLE_WORKERS=true) and detailing the statistics returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the core purpose and then adds the key availability constraint without any redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only stats tool, the description is complete: it states what the tool does, what data it returns, and the environment flag required. No additional input or safety context is needed given the rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter meaning beyond the schema. With no parameters, the baseline is 4, and the description appropriately focuses on output scope rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a precise resource ('worker thread pool statistics'), listing the exact data returned. This clearly distinguishes it from sibling stats tools like cache_stats and deprecation_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when worker thread pool statistics are needed. It also provides a clear prerequisite and exclusion: the tool is only available when ENABLE_WORKERS=true, signaling not to use it otherwise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v4.1.0cyberchef_analysecyberchef_categories1 field changedOutput schema / properties / analysisToolsAdded value: +{
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "tools": {
+ "items": {
+ "properties": {
+ "title": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tool",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "usage": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "count",
+ "description",
+ "tools",
+ "usage"
+ ],
+ "type": "object"
+}cyberchef_cert_chaincyberchef_classical_ciphercyberchef_corpus_diffcyberchef_crib_dragcyberchef_cyclic_patterncyberchef_deprecation_statscyberchef_ecdsa_recovercyberchef_entropy_scancyberchef_hash_crackcyberchef_hash_identifycyberchef_hash_statisticscyberchef_jwt_weaknesscyberchef_migration_previewcyberchef_plaintext_checkcyberchef_rsa_attackcyberchef_rsa_multi_keycyberchef_substitution_breakcyberchef_timestamp_identifycyberchef_vigenere_breakcyberchef_xor_key_lengthv3.8.0cyberchef_cert_chainv3.6.0cyberchef_bakecyberchef_batchcyberchef_cache_clearcyberchef_cache_statscyberchef_categoriescyberchef_classical_ciphercyberchef_corpus_diffcyberchef_crib_dragcyberchef_cyclic_patterncyberchef_deprecation_statscyberchef_describe_operationcyberchef_ecdsa_recovercyberchef_entropy_scancyberchef_hash_crackcyberchef_hash_identifycyberchef_hash_statisticscyberchef_jwt_weaknesscyberchef_list_operationscyberchef_magiccyberchef_migration_previewcyberchef_plaintext_checkcyberchef_quota_infocyberchef_recipe_createcyberchef_recipe_deletecyberchef_recipe_executecyberchef_recipe_exportcyberchef_recipe_getcyberchef_recipe_importcyberchef_recipe_listcyberchef_recipe_testcyberchef_recipe_updatecyberchef_recipe_validatecyberchef_rsa_attackcyberchef_rsa_multi_keycyberchef_searchcyberchef_substitution_breakcyberchef_telemetry_exportcyberchef_timestamp_identifycyberchef_vigenere_breakcyberchef_worker_statscyberchef_xor_key_lengthScored across 23 tools
Most tools are distinct, but cyberchef_recipe_execute, cyberchef_bake, and cyberchef_batch overlap heavily in executing operations/recipes; the description clarifies that bake is for complex chains and batch for multiple operations, but the boundaries remain fuzzy for an agent.
All tools follow the consistent prefix_noun_verb pattern (cyberchef_recipe_delete, cyberchef_list_operations, etc.), making the set predictable and scannable.
23 tools is on the heavy side for a single domain; the 10 recipe lifecycle tools are justified, but cache, worker, quota, and telemetry stats tools add operational overhead that feels tangential to core CyberChef usage.
Recipe lifecycle is fully covered (create, get, list, update, delete, test, validate, import, export, execute), and operation discovery plus analysis tools are present; minor gaps include no direct recipe duplicate/copy or operation-level metadata export.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
AI-security knowledge as MCP: standards-mapped tools (OWASP, NIST, MITRE) for AI agents.
65+ AI tools as MCP: research, write, code, scrape, translate, RAG, agent memory, workflows
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
