CyberChef MCP Server

cyberchef_analyse

Read-onlyIdempotent

Run CyberChef analysis tools for tasks a single operation cannot handle: hash identification, XOR key-length recovery, cipher solving, X.509 chain validation, and post-quantum key identification.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tool": "<tool>"
    },
    "name": "cyberchef_analyse"
  }
}

Input Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv4.1.0Sep 12, 2026

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.