Click on "Install 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 API MCP Server decode this base64 string: SGVsbG8gV29ybGQ="
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 model context protocol (MCP) server interfaces with the CyberChef Server API. Allowing you to use any LLM/MCP client of your choosing to utilise the tools and resources within CyberChef.
get_cyberchef_operations_categories: resource - gets updated Cyber Chef categories for additional context / selection of the correct operations
get_cyberchef_operation_by_category: resource - gets list of Cyber Chef operations for a selected category
bake_recipe: tool - bake (execute) a recipe (a list of operations) in order to derive an outcome from the input data
batch_bake_recipe: tool - bake (execute) a recipe (a list of operations) in order to derive an outcome from a batch of input data
perform_magic_operation: tool - perform CyberChef's magic operation which is designed to automatically detect how your data is encoded and which operations can be used to decode it
Related MCP server: CyberChef MCP Server
Start the server using the default stdio transport and specifying an environment variable pointing to a CyberChef API
CYBERCHEF_API_URL="your-cyberchef-api-url" uv run cyberchef_api_mcp_serverStart the server and test it with the MCP inspector
uv add "mcp[cli]"
mcp dev server.pyThe following commands will generate a client configuration file, the location will depend on your operating system
uv add "mcp[cli]"
mcp install server.py --name "CyberChef API MCP Server"After running the above command you can then tweak the client configuration to include the environment variable for the CyberChef API URL
{
"mcpServers": {
"CyberChef API MCP Server": {
"command": "uv",
"args": [
"run",
"--with",
"mcp[cli]",
"--directory",
"cyberchef-api-mcp-server/cyberchef_api_mcp_server/",
"mcp",
"run",
"server.py"
],
"env": {
"CYBERCHEF_API_URL": "your-cyberchef-api-url"
}
}
}
}Using the MCP server in this example use case, the following prerequisites apply:
You must have Claude desktop installed
Have a running CyberChef API instance or one you are able to use
Here is a basic prompt being solved using the MCP server tools:
MIT License
Bake (execute) a recipe (a list of operations) in order to derive an outcome from the input data
:param input_data: the data in which to perform the recipe operation(s) on
:param recipe: a pydantic model of operations to 'bake'/execute on the input data
:return:
| Name | Required | Description | Default |
|---|---|---|---|
| input_data | Yes | ||
| recipe | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry full behavioral burden. It describes the action (bake/execute) but fails to disclose side effects, data mutability, or required permissions. Essential traits like destructiveness or state changes are absent.
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?
Description is short and front-loaded with the action, followed by param docs. No wasted words, though param docs could be more precise.
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?
Missing critical context: no output schema, no explanation of return values, ordering of operations, error handling, or relationship to sibling tools. For a tool with two required params and no annotations, this is insufficient for an AI agent to use correctly.
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 description adds basic param meaning: input_data is the data to operate on, recipe is the list of operations. However, it inaccurately calls recipe a 'pydantic model' when it's an array, and lacks detailed guidance on constructing the recipe. With 0% schema coverage, this is only modestly helpful.
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 bakes/executes a recipe to derive an outcome from input data. It distinguishes from siblings like batch_bake_recipe who likely processes multiple recipes, but does not explicitly differentiate.
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 on when to use this tool versus alternatives. The description implies usage for executing a single recipe, but lacks conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bake (execute) a recipe (a list of operations) in order to derive an outcome from a batch of input data
:param batch_input_data: the batch of data in which to perform the recipe operation(s) on
:param recipe: a list of operations to 'bake'/execute on the input data
:return:
| Name | Required | Description | Default |
|---|---|---|---|
| batch_input_data | Yes | ||
| recipe | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It states it executes/derives outcomes but does not disclose side effects, permissions required, error handling, or return behavior. For a mutation tool, this is insufficient.
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?
Reasonably concise with a clear purpose statement followed by parameter descriptions. The docstring style is appropriate, though the :param lines are somewhat redundant with the schema.
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?
Missing critical context: no output schema, no error behavior, no mention of batch vs single differences. Given the complexity of executing recipes on batches, more detail is needed to ensure correct usage.
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 0%, so the description adds value by explaining parameters: 'batch_input_data' as the batch to operate on, 'recipe' as a list of operations. However, it lacks details like allowable data types (already in schema) or constraints on recipe structure.
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 it bakes/executes a recipe on batch input data. The verb 'Bake' is specific, and the resource 'recipe' is well-defined. However, it does not explicitly differentiate from sibling tools like 'bake_recipe' (single vs batch).
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 on when to use this tool versus its siblings (bake_recipe, perform_magic_operation). Lacks context for appropriate invocation scenarios or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CyberChef's magic operation is designed to automatically detect how your data is encoded and which operations can be
used to decode it
:param input_data: the data in which to perform the magic operation on
:param depth: how many levels of recursion to attempt pattern matching and speculative execution on the input data
:param intensive_mode: optional argument which will run additional operations and take considerably longer to run
:param extensive_language_support: if this is true all 245 languages are supported opposed to the top 38 by default
:param crib_str: argument for any known plaintext string or regex
:return:
| Name | Required | Description | Default |
|---|---|---|---|
| input_data | Yes | ||
| depth | No | ||
| intensive_mode | No | ||
| extensive_language_support | No | ||
| crib_str | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'speculative execution' and that intensive_mode takes longer, providing some behavioral insight. However, it lacks details on side effects, authentication needs, or limits.
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 docstring with parameter explanations, which is structured but somewhat verbose. It could be more concise by separating the core function from parameter details.
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 5 parameters, no output schema, and complex behavior, the description covers parameter purposes but does not explain return values or constraints. It is adequate but 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 0%, but the description explains each parameter: input_data, depth, intensive_mode, extensive_language_support, and crib_str. This adds significant meaning beyond the schema's raw fields.
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 that the tool automatically detects encoding and operations to decode data, which is a specific verb-resource purpose. It distinguishes from sibling tools like bake_recipe and batch_bake_recipe by focusing on automatic detection rather than direct baking.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools present, there is no explicit mention of trade-offs or exclusion criteria.
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. Dates show when Glama detected each change.
v0.1.0bake_recipebatch_bake_recipeperform_magic_operationbake_recipe and batch_bake_recipe are clearly distinct (single vs batch input), but their similarity could cause confusion. perform_magic_operation is distinct.
All tools use snake_case and verb_noun pattern (bake_recipe, batch_bake_recipe, perform_magic_operation), though 'perform' is less typical than 'bake'.
3 tools is slightly low but appropriate for a focused CyberChef wrapper; covers baking and magic detection without being overly minimal.
Covers core recipe execution and auto-detection, but missing tools for exploring available operations or constructing recipes, which are typical needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/slouchd/cyberchef-api-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
