Loading ToolBench
MCP server that has the ability to interact with the CyberChef server RESTful API
This server has 3 tools with explicit registration and schemas visible in the source code. All three tools have basic descriptions and input schemas, but the schemas lack depth and parameter descriptions are minimal or absent. The tools perform coherent, focused operations (recipe execution and magic detection), but descriptions are sparse (under 100 chars for most parameters) and schemas are under-documented. Error handling is not evident in the source, responses are passed through from the upstream API without LLM-actionable guidance. No tool annotations (readOnlyHint, destructiveHint) are present despite all tools being READ_ONLY. The batch variant (batch_bake_recipe) is present but names could be more discoverable. Overall, this is a fair-to-poor implementation that follows basic structure but lacks production-grade documentation and error handling.
Bake (execute) a recipe (a list of operations) in order to derive an outcome from the input data
Bake (execute) a recipe (a list of operations) in order to derive an outcome from a batch of input data
CyberChef's magic operation is designed to automatically detect how your data is encoded and which operations can be used to decode it
Parameter descriptions are minimal or absent. The 'recipe' parameter is described as 'a pydantic model of operations' with nested 'op' and 'args' fields, but there are no descriptions for the nested fields ('op', 'args'). LLMs cannot infer what operation names are valid or what args format each operation expects.
No error handling guidance. The tools call create_api_request() which returns {'error': '...'} on failure, but there is no documentation of what errors the LLM should expect, how to recover, or what to do next. A generic HTTP error message tells the LLM nothing actionable.
No tool annotations despite all tools being READ_ONLY. The @mcp.tool() decorators lack readOnlyHint=true or any destructive/idempotent markers. The server metadata declares risk='READ_ONLY' but the MCP protocol annotations are not used.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Output schemas are not documented. Tools return dict objects from the CyberChef API, but there is no description of the structure (e.g., does 'bake_recipe' return {value, type, status}? What fields does 'perform_magic_operation' include?). LLMs cannot plan downstream calls or extract results.
No enum constraints on 'operation_name' or 'args'. The 'op' parameter accepts a free-form string with no list of valid CyberChef operations. While CyberChefOperations class exists and resources expose operation categories, tools do not hint to the LLM which operations are valid before calling bake.
Resource-based discovery exists but tools do not link to it. Resources 'data://cyberchef-operations-categories' and 'data://cyberchef-operations-by-category/{category}' are defined but tool descriptions do not mention 'call get_cyberchef_operations_categories() first to see available operations'.
Parameters 'depth', 'intensive_mode', 'extensive_language_support' in perform_magic_operation have defaults but no rationale. Why default to depth=3? Why is intensive_mode false by default? Descriptions should explain when to override defaults.