Skip to main content
Glama

cyberchef_bake

Execute multi-stage CyberChef recipes to encode, decode, deobfuscate, or analyze strings. Supports Base64, XOR, AES, hashing, entropy, JWT, and more.

Instructions

Executes a multi-stage sequential data transformation pipeline ('recipe') on the input string across 28 core CyberChef operations (Base64, Hex, URL, HTML entities, XOR, ROT13, AES-CBC Encrypt/Decrypt, MD5, SHA1, SHA256, SHA512, Entropy, Magic, JWT, Defang, Dual-stack IP, DLP entities, Strings, JSON Beautify, Regex, Reverse, Find/Replace). Limits: 5000ms execution timeout, 10MB memory cap per recipe.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesThe raw, encoded, or obfuscated input string to process through the transformation pipeline.
recipeYesOrdered array of recipe steps to execute in sequence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.4
    • changedInput schema / properties / input / description
      Previous value: -"The raw, encoded, or obfuscated input string to process through the transformation pipeline. Can be plain text, hex-encoded bytes, Base64 strings, or URL-encoded parameters."New value: +"The raw, encoded, or obfuscated input string to process through the transformation pipeline."
    • changedInput schema / properties / recipe / description
      Previous value: -"Ordered array of recipe steps to execute in sequence. Example: [{'op': 'From Base64'}, {'op': 'URL Decode'}]"New value: +"Ordered array of recipe steps to execute in sequence."
    • changedInput schema / properties / recipe / items / properties / args / description
      Previous value: -"Optional array of arguments required by the operation (e.g. ['secret'] for XOR key, or [13] for ROT13 offset). If omitted, operation defaults are used."New value: +"Optional arguments for the operation (e.g. ['key'] for XOR, [13] for ROT13, [key, iv, 'CBC'] for AES)."
    • changedInput schema / properties / recipe / items / properties / op / description
      Previous value: -"The canonical name of the CyberChef operation to apply. Supported operations include: 'From Base64', 'To Base64', 'From Hex', 'To Hex', 'URL Decode', 'URL Encode', 'XOR', 'ROT13', 'MD5', 'SHA256', 'Defang URL', 'Refang URL', 'Entropy', 'Extract URLs', 'Extract Emails'."New value: +"The canonical name of the CyberChef operation (e.g. 'From Base64', 'To Hex', 'URL Decode', 'XOR', 'ROT13', 'AES Encrypt', 'AES Decrypt', 'MD5', 'SHA256', 'Defang URL', 'Regular expression')."
  2. Changed4 schema fields changedv1.0.2
    • changedInput schema / properties / input / description
      Previous value: -"The raw or encoded input string to transform"New value: +"The raw, encoded, or obfuscated input string to process through the transformation pipeline. Can be plain text, hex-encoded bytes, Base64 strings, or URL-encoded parameters."
    • changedInput schema / properties / recipe / description
      Previous value: -"Array of recipe steps to execute in sequence"New value: +"Ordered array of recipe steps to execute in sequence. Example: [{'op': 'From Base64'}, {'op': 'URL Decode'}]"
    • changedInput schema / properties / recipe / items / properties / args / description
      Previous value: -"Optional arguments for the operation"New value: +"Optional array of arguments required by the operation (e.g. ['secret'] for XOR key, or [13] for ROT13 offset). If omitted, operation defaults are used."
    • changedInput schema / properties / recipe / items / properties / op / description
      Previous value: -"Operation name, e.g., 'From Base64', 'URL Decode', 'From Hex'"New value: +"The canonical name of the CyberChef operation to apply. Supported operations include: 'From Base64', 'To Base64', 'From Hex', 'To Hex', 'URL Decode', 'URL Encode', 'XOR', 'ROT13', 'MD5', 'SHA256', 'Defang URL', 'Refang URL', 'Entropy', 'Extract URLs', 'Extract Emails'."
  3. First observedv1.0.1

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It does add valuable operational context — a 5000ms execution timeout and 10MB memory cap per recipe — which is exactly the kind of limit an agent needs. But it says nothing about the return format, error behavior, or whether operations are sandboxed, leaving those gaps for a no-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences, front-loaded with the core purpose followed immediately by the operational limits. Every clause contributes either scope (what it does, what operations) or constraints (timeout, memory) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex multi-stage pipeline with no output schema and no annotations, the description supplies the operation list and execution limits, which covers most invocation concerns. It omits what the tool returns (presumably the transformed string) and how errors/timeouts are surfaced, which an agent would need to interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by enumerating the supported operation categories (Base64, Hex, XOR, AES-CBC, MD5, JWT, Defang, etc.), which helps the agent reason about valid recipe contents beyond the schema's brief examples. The listing uses category names rather than exact canonical operation strings, so it does not fully replace the schema's guidance.

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 ('Executes') and resource ('multi-stage sequential data transformation pipeline/recipe') and distinguishes itself from single-operation siblings like cyberchef_from_base64 by explicitly being a pipeline. The list of 28 supported operation categories tells the agent the scope of the tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Use is implied by 'multi-stage sequential data transformation pipeline' — an agent can infer it is for chaining operations rather than one-off steps. However, it never explicitly says when to use this tool versus the many single-operation siblings, nor does it name any alternative or exclusion condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.